| |
| |
On 7/21/21 12:02 PM imm wrote:
On Tue, 20 Jul
2021, 18:38 Albrecht Schlosser wrote:
That would be a strong reason not to use std::stuff in
FLTK, even today - if it would still be the case.
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.
OKAY, I withdraw my request to consider using std::vector etc..
There's no need to test. Thanks.
Thinking about the problem, the only valid answer we could get from
testing is that it doesn't work. If it works, the basic question is
still not answered: are there other systems that rely on FLTK and
which can't use std:: stuff.
I believe the only logical conclusion is:
(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...
... and I think that's what we need to do as well.
Thanks for reading and replying so far. IMHO this thread is now
done.
I'll evaluate using already existing FLTK and maybe new classes and
open another thread when I have something usable.
--
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/1e3fcfd2-217d-994f-4fa5-cc6b1dc1b3a0%40online.de.
[ Direct Link to Message ] | |
|
| |
