Re: [fltk.coredev] Consider using std::vector (C++98 / C++11)

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Consider using std::vector (C++98 / C++11) imm 03:02 Jul 21 top right image
 
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.
-- 
Ian
From my Fairphone FP3

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/CAGFM6db5iADr50-hndgAoFfo_ZgBQd-ttUTVoQO7gBFnqAxvDQ%40mail.gmail.com.
Direct Link to Message ]
 
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.