Poll #11

i personally think it's an good idea to use the stl internally for fltk, such that the code complexity if fltk itself is reduced. lesser number of code lines is always equivalent with fewer bugs - and with stl this can be achived for sure. besides - is there any modern c++ compiler that does'nt come along with an stl-lib ?
[ Reply ]

From Anonymous, 14:17 Jun 11, 2003 (score=1)

Yes, there is. According to my own experience, there's no problem under Unix, if you use GCC. But the only working STL I've seen under Windows is MinGW's. I haven't tried every flavor, but:

1) Borland C++ Builder: sucks. Has such memory management problems that the mere use of the string class in a resource-intensive program brings Windows 2000 on its knees. I mean, it crashes so bad the only thing we can do is power down the computer.

2) MSVC6: I tried to port a library I wrote under Windows using that. The lib built fine under GCC 3.2. Got 477 errors *in VC own include files*. I can't believe they're using this in professional environments. Changed the number of errors just by modifying the #include order. Still doesn't compile. Gave up.

Anyway, I think it would be great to be able to use STL algorithms with some FLTK classes, but this would obviously break down the cross-platform thing. And besides, as someone else stated, the code-bloat traditionally associated with STL would negate FLTK's usefulness.
[ Reply ]

From Myren, 22:42 Sep 08, 2004 (score=1)

wow, there are architectures without real stl's? i thought that went the way of punchcards 5 years ago somehow.

gcc never ceases to amaze, i guess.
[ Reply ]

From Mike Sweet, 15:02 Jan 15, 2003 (score=1)

First, STL is not universally supported yet, and more importantly the version of STL varies substantially. For that reason alone, we won't be depending on STL for the functioning of FLTK.

Another reason not to use STL is that STL code, while time efficient and helpful in reducing implementation bugs, is not space efficient. Since one of the primary goals of FLTK is space efficiency (small size), that is another strike against using STL internally.
[ Reply ]

From Sean McInerney, 12:02 Apr 11, 2004 (score=2)

I think STL can dramatically simplify, standardize, and improve library implementation. The resources and time that have gone into its development and testing should not be overlooked. Its usage, however, should be banned from header files with the possible exception of <iosfwd> for use in error/warning/debug output and/or serializing as well as <stdexcept> if exception support is desired. Inclusion of STL headers incurs the enormous compile time burden of nested templates and associated inner mysteries.

An effective compromise is achieved via the "PIMPL idiom" whereby STL types are encapsulated within forward declared private types that are defined within the implementation file (whew!). A less compressed explanation of this idea can be found by searching the web for "pimpl idiom".

Additionally, crappy compilation evironments (read win32) seem to choke on namespace usage in the STL (and elsewhere). This can generally be alleviated through some clever hackery ... I would suggest looking at Xerces-C or VTK for approaches to this problem.

This approach necessarily rules out user access to STL iterator types and any straightforward user application of STL algorithms to FLTK widgets ... but I doubt that this is a major loss. C is for cookie, STL is for implementation, and that's good enough for me.
[ Reply ]

From Anonymous, 14:40 Sep 25, 2004 (score=1)

STL is wonderful, but the implementations vary greatly at times and would complicate the porting process.

I think fltk should use macros to approximate class templates in order to make the code that much more portable.
[ Reply ]

From Anonymous, 01:09 Jan 13, 2003 (score=1)

I consider it to be far more important that FLTK should work together well with STL than that it should use it. I don't give a shit if it uses std::vector for managing widgets and stuff, as long as it would e.g. provide iterators to access the associated widgets with standard algorithms.

What I like most about FLTK is that it can easily be fitted into my programming model, e.g. I can multiple inherit from FL_Button and from my own class - typically an interface class - to decouple GUI code from and interface logic code. This is in marked constrast to other GUI kits like QT - which otherwise I happen to like a lot - where a class that derives from QObject cannot also derive from a class which doesn't.

I'd really appreciate FLTK to stick with this don't-impose-a-policy-on-the-users attitude. Templates can help with this, if you define generic access functions, but they can also make it more difficult, if you hardcode certain STL constructs and force the user to work with them.

Using STL entities as a default is not a problem, but you have to make it possible for the user to work with alternative implementations like STLPort without unduly difficult work.
[ Reply ]