On 04/16/12 11:14, Edzard Egberts wrote:
> > Since FLTK is targeted at platforms which often lack complete ISO C++
> > support or have limited memory, all C++ code in FLTK must use a
> > subset of ISO C++.
>
> What's about today, are these restrictions state of the art?
>
> Exceptions
> Namespaces
> Standard C++ headers and library
> Templates
> static_cast, dynamic_cast, const_cast
>
> I'm in doubt of Exceptions, but I love using STL and I don't like char*.
> To me it's not C++ without STL, at the very most a C+.
>
> > We'd need one or the other to add ABI-breaking changes
>
> FLTK_3.unrestricted.playground? I really don't like char*. ;o)
Mmm, it would be good to figure this out ASAP,
as some stuff coming down the pipe might affect this.
Domingo/Fabien have been considering to import FLU,
which IIRC includes a string library of some kind.
This hasn't been accepted for inclusion yet by the devs,
but other widgets have a growing need for dynamic strings
and templates as well.
To this day I'm not sure if embedded compilers support
things like templates (and by extension, STL) so using
templates inside FLTK would affect those folks.
However, FLTK 3.x might be an opportunity to draw the line
between 'ancient' compilers, and semi-modern ones.
Arguably, a C++ compiler that doesn't support templates
isn't a C++ compiler, so why should we continue to limit
FLTK's development.
If FLTK 3.x decides to use templates, the folks with 'old'
compilers will be stuck with the 1.3.x branch, which should
be fine with them; if they want newer features the more
advanced widgets bring, they'll have to pressure vendors
to support better compilers, and get those vendors out
of the last century.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
