| |
| |
On 7/19/21 12:23 PM imm wrote:
On Thu, 15 Jul 2021, 19:38
Bill Spitzak wrote:
Back when fltk was created using std::
stuff was certainly much worse performance and storage
wise compared to directly writing pointer manipulation
like in C. However that has certainly changed over time,
modern implementations especially on Linux are highly
optimized. I suspect using std::vector<FlWidget*>
everywhere possible would not cause any problems or
incompatibility, the old widgets did hide the
implementation pretty well.
Meant to reply to this ages ago... But forgot...
I got caught out by this a while back (might
have been list rather than vector, but anyway...) where I'd
updated a block of embedded code. In testing (on Windows) this
went really well.
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.
The implementation may be "better" now of course
but that's what happened back then.
Any chance to test on your [oldest | most primitive] embedded
platforms, cross-compiler suites, or ... ?
The other key is not to expose the template in
the API, as I've hit weird issues with that, where I think the
compiler implemented the API differently between two modules
due to... Something? Optimization settings? Don't know;
compiled OK but choked in weird ways at runtime!
My intention was not to expose template code in the API. The only
reason to use it would be simplification of internal code.
Allocating varying size arrays and reallocating everywhere we need
them is a code maintenance issue. Of course it can be done, but it's
likely more code and error prone.
I'm thinking of new widgets that need more arrays than only the list
of children. Layout stuff for instance, be it row/column [1] or grid
[2] oriented.
There's also GitHub Issue #153 [3] and STR #3290 [4]. I'd say the
biggest part of the solution is to avoid std::vector by including
some own FLTK classes [5] [6]. This should at least be standardized
(see below, solution (2)).
There are other (similar) solutions already included in FLTK, e.g.
FL/Fl_Table.H:157: // An STL-ish vector
without templates
FL/Fl_Table.H:158: class FL_EXPORT IntVector {
FL/Fl_Table.H:167: IntVector() { init();
} // CTOR
FL/Fl_Table.H:168:
~IntVector(); //
DTOR
FL/Fl_Table.H:169: IntVector(IntVector&o) { init();
copy(o.arr, o._size); } // COPY CTOR
FL/Fl_Table.H:170: IntVector& operator=(IntVector&o)
{ // ASSIGN
FL/Fl_Table.H:184: IntVector _colwidths; //
column widths in pixels
FL/Fl_Table.H:185: IntVector _rowheights; // row
heights in pixels
FL/Fl_Table_Row.H:52: // An STL-ish vector without templates
FL/Fl_Table_Row.H:53: class FL_EXPORT CharVector {
FL/Fl_Table_Row.H:62: CharVector()
{ // CTOR
FL/Fl_Table_Row.H:65:
~CharVector(); // DTOR
FL/Fl_Table_Row.H:66: CharVector(CharVector&o)
{ // COPY CTOR
FL/Fl_Table_Row.H:70: CharVector&
operator=(CharVector&o) { // ASSIGN
src/Fl_Help_View.cxx:7:// Buffer management (HV_Edit_Buffer) and
more by AlbrechtS and others.
src/Fl_Help_View.cxx:292:class HV_Edit_Buffer {
src/Fl_Help_View.cxx:302: HV_Edit_Buffer (int alloc = 1024, int
ext = 1024); // c'tor
src/Fl_Help_View.cxx:303: ~HV_Edit_Buffer
(); // d'tor
This list could likely be continued.
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.
How to find a solution? If we find at least one supported
application/platform/system that does not allow us to use std::
stuff then we must use solution (2).
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).
Comments from everybody would be appreciated, particularly if an
application/platform/system would NOT allow to use std:: stuff when
building FLTK.
Thanks in advance.
- - - Links - - -
[1] A potential candidate Fl_Flex uses std::vector internally, see
GitHub Issue #255:
https://github.com/fltk/fltk/issues/255
https://github.com/osen/FL_Flex/blob/main/FL_Flex.H
[2] A potential "Fl_Grid" widget (no candidates yet) would need all
sorts of variable sized arrays (Issue #256):
https://github.com/fltk/fltk/issues/256
[3] https://github.com/fltk/fltk/issues/153
[4] https://www.fltk.org/str.php?L3290
[5] https://github.com/fltk/fltk/issues/153#issuecomment-756027342
[6] https://github.com/fltk/fltk/files/5780975/ol.diff.txt
--
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/4115a83c-f45a-6544-2a61-efef4617aee2%40online.de.
[ Direct Link to Message ] | |
|
| |
