| |
| |
On 10/29/21 11:32 AM, Albrecht
Schlosser wrote:
On
10/29/21 7:27 PM Karsten Pedersen wrote:
(2) Very happy to. Though do I need to
look up at how FLTK deals with operator new() throwing
exceptions on OOM situations.
We don't. ;-)
Right -- it's up to the app to trap such exceptions if
interested in them, but FLTK
does not throw or catch exceptions itself.
For handling new in my daemon application, I used a hook (I
forget the details)
to hook into both new and malloc() so that out of memory
conditions basically
retry with a sleep until it succeeds, preventing a crash due
to the machine being
overloaded by, presumably, some other application that will
eventually be killed
by the OOM killer or a user.
I don't ever try to handle out of memory conditions in the
app; the best thing IMHO
is to wait a little and try again so that a memory allocation
never fails.
(3) std::string is easy, I barely use it.
I could just use standard C-Style strings. I will have a look
through FLTK and see what you guys use for containers. If not I
can put together some C-style linked list, etc.
We don't use any containers yet (officially) although there are
some (inofficial, i.e. not public) containers used in some
implementations, for instance Fl_Table::IntVector. Picking
existing container types, putting them in classes etc., making
them kinda "protected" or "public" is on my todo (ehm, wish) list
though. With "protected" I mean in this context that they could be
inside the library code base but not in the public header files.
Public would mean that they'd be in the FL/ directory for public
usage.
Bill wrote in his comment "I don't have any problem with using
std::vector, it was not used back in the day because it used much
more memory and was slower than naive C implementations, but this
is not true any more." We *might* reconsider using std::vector in
the future which would simplify some, particularly new code.
OTOH the strings used could likely be simple char* arrays as Bill
mentioned as well.
Our main concern with the std:: stuff is old compilers that
support C++ but not templates.
These days that falls into embedded hardware with limited
abilities, and/or really old
operating systems, I think someone was able to get FLTK to run
under DOS even (!),
using some kind of custom graphics that talks directly to
hardware without a window manager.
"Back in the day" in the 90's that Bill was talking about, STL
was a separate package
and it didn't even work with most of the SGI compilers we were
using back then, as
they didn't even support templates at all until much later. As
far as I can recall, my
most recent SGI native compiler config from the 2000's did not
support templates ("CC"),
but I think if you used gnu c++ you could use STL.
IIRC, STL was eventually brought into one of the C++ standards
and now the compilers
"come with STL" as part of the standard. While I am not at all a
fan of STL's API, I use it
in new applications.. but I'm glad FLTK doesn't use it. Errors
from the template library
are horribly ugly, and the API makes me barf. Vectors should
have been called arrays,
'push_back()' instead of 'append()', and 'back()' instead of
'last()', and lots of simple
use cases (like deleting an element) are horribly byzantine..
oof, there I go again on a rant.
(5) OK, I will push to my repo on GitHub
an LGPL LICENSE file. I can perhaps grab one with the exceptions
in it from the FLTK project repo.
Great.
Yes, I did that with all my donations to FLTK as well
Fl_Input_Choice, Fl_Table, Fl_Tree;
FLTK's license is the standard LGPL 2 with a static compile
exception, and some recommendations
for handling credits that are I think optional IIRC.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/3c1cb016-c26a-e0f1-8cb7-30342cdf16dc%40seriss.com.
[ Direct Link to Message ] | |
|
| |
