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) Albrecht Schlosser 10:38 Jul 20 top right image
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:

[2] A potential "Fl_Grid" widget (no candidates yet) would need all sorts of variable sized arrays (Issue #256):


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
To view this discussion on the web visit
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 ''.