On Tue, 20 Jul 2021, 18:38 Albrecht Schlosser wrote:
But the embedded version wouldn't even compile.
The key was that the gcc std lib *required*
exception support, whereas the MS implementation did not. Our
embedded targets don't support exceptions (not enough RAM and
nowhere to propagate to anyway.) So that was the end of that!
That would be a strong reason not to use std::stuff in FLTK, even
today - if it would still be the case
Just for clarity, I should emphasize I was not trying to get fltk running on the target, nor do I desire to.
Rather, I was wanting to note the unexpected dependency on exception support, which fltk has traditionally avoided.
The toolchain used was gcc-4.3, so pretty old (2008 or so) but that's not unusual for embedded tools.
The Windows prototype was also tested with gcc-4.3 (from mingw) but worked. It turns out that uses the MS std:: implementation, I think, which does not have that dependency.
I *think* I heard that dependency on exception is removed in later std:: lib versions but I do not know and can't currently test.
Any chance to test on your [oldest | most primitive] embedded
platforms, cross-compiler suites, or ... ?
I'll try, but can't at the moment. May be a week or so yet...
However, my oldest/most primitive targets will never run fltk anyway, so they're not a constraint. I guess we'd need to determine which tools would be a problem... Somehow.
I'd like to find a good solution for different kinds of vectors
(variable size arrays) or maybe stacks or whatever we need:
(1) If we can use std:: stuff w/o compatibility issues: allow a
selected subset of std::vector< ... > for internal usage
beginning with FLTK 1.4.0.
(2) If we can't use it, create some internal FLTK classes we can use
"everywhere" internally. These classes need not (must not?) be
exposed in the public FLTK API.
This is, in effect, the path I took...
Ian, hence my question: would your (current) needs allow or disallow
std::vector (etc.) stuff? If not we're done (solution 2), if yes the
question remains open (needs more input).
I do not know if any of the targets on which I currently run fltk have this constraint but I *believe* that they do not. Will check in due course.
The targets that I know for certain do have this constraint are not able to run fltk anyway.
From my Fairphone FP3