On 14 Feb 2010, at 11:04, Dufour wrote:

> I have a very simple question. Do you plan to use more C++ features  
> in the future for FLTK? Like std::string, functors, STL, etc...

This question, or some similar variant of it, comes up every now and  
then - so far the answer has always been; well, probably not.

Historically, the issue has always been one of ensuring portability  
and reliability - note that many of the "C++ features" people ask for  
- e.g. std::string, STL, etc... - are not part of the language  
definition per se, they are part of the surrounding infrastructure  
around the language core, and historically they have not been as  
widely or consistently available cross-platform.
Things get better, but are still some way short of the cross-platform  
consistency achieved by the C standard libraries, for example.

Of course, you can use any or all of these extensions with fltk in  
your own code; indeed I often use STL containers for managing lists  
of items and widgets these days myself, though I have had issues with  
the differences in STL implementations between linux and win32, for  
example.

> If you use many of C++ strengths, I am sure that the library will  
> still be very light, and even more pleasant to use.

As I say, you can readily use these features yourself in your own code.
When it comes down to it - where do you see them being used in fltk  
itself? How do you envisage those additions / changes being made  
without breaking the API and or ABI compatibility that we strive so  
hard to maintain?

And lastly - FL == Fast & Light.
Make a little statically lined code with inline methods; make some  
functionally equivalent code with templates. Check the relative sizes  
and execution speeds... templates work, but in the majority of cases  
(i.e. any case where the "mapping" is so trivial you probably didn't  
need it in the first place!) they require a lot more indirection,  
some of which is resolved at execution time, making the code bigger  
and slower.
A perfectly valid choice, but not what we want for FL...



_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to