Dufour wrote:
> Hello everyone !
>
> 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... If you use many of
> C++ strengths, I am sure that the library will still be very light, and even
> more pleasant to use.
Although I hesitate to reply on these cause it can spark long vi/emacs
threads,
it's always therapeutic. ;)
There's been hesitance for FLTK to adopt the std library to ensure FLTK
will
compile on minimum platforms (embedded hardware, cell phones, etc)
which often
only support subsets of the advanced C++ template features. And this
would
prevent FLTK from building on those platforms.
That's the main reason its been passed over by FLTK.
That info is somewhat dated though.. it's possible many embedded
platforms
support std by now, but I'm not sure. I think there were more recent
votes
on this, I don't recall the outcome.
It might be time to re-evaluate this, but IMHO nothing stops FLTK app
programmers
from using std libs, it's just FLTK itself internally prefers not to
use it for
portability. So it shouldn't really affect someone writing apps.
I personally have a distaste for std, even though I use it. So everyone
don't
be offended if you disagree; I know I'm probably in some minority on
this.
My main distaste for std its unintuitive, alien syntax, and how complex
its internals are, esp. since these get exposed to the app programmer
through
compiler errors and during debugging, due to how it's implemented
mostly in
#include files.
For instance, while developing an application, I received the following
insane error message from the compiler about a small mistake in a line
that removes elements from a vector:
test.cxx: In function 'int main()':
test.cxx:24: error: no matching function for call to
'std::vector<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >
::erase(__gnu_cxx::__normal_iterator<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >*, std::
vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,
std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > > >,
__gnu_cxx::__normal_iterator<std::basic_string<char, std::char
_traits<char>, std::allocator<char> >*, std::vector<std::basic_string<char,
std::char_traits<char>, std::allocator
<char> >, std::allocator<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > >, std::string)'
This is the longest single line error message I think I've ever scene
from a C++ compiler.
The only useful information in there was the problem occurred on Line
24.
When I see that, I think 'this has not been gracefully integrated into
the compiler',
and whether its part of the language or not seems academic.
I'm also not a fan of the std syntax which I find overly engineered and
"alien"
in the context of C/C++. Doing simple things is often very hard, and
the syntax
completely unintuitive. I don't know much about how std was developed,
but it seems
like "too many smart people" were involved, and not enough input from
dumb practical
people. Anything that makes me feel dumb I don't like. ;)
Regardless, std is something I use in projects unrelated to FLTK, and
it's hard to
avoid when you need a strong string library or dynamic arrays, hashes,
etc.
as its ubiquitous. I've used it in FLTK apps before; you just have to
use c_str()
when passing in strings, or write wrapper methods to convert FLTK
'arrays of pointers'
to std vectors, arrays, hashes, etc. depending on what you need.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
