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

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   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) Rob McDonald 18:12 Jul 23 top right image
On Friday, July 23, 2021 at 6:14:46 AM UTC-7 Albrecht Schlosser wrote:

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.

While this may well be the pragmatic answer in this case, as an overall philosophy it is greatly disheartening and wholly unsatisfying.

It seems that forward progress will always be curtailed by a ghost in the room.  Some notion of long-dead systems that carry a veto lest we ever offend them.

I'm a big fan of supporting legacy systems and not breaking things -- even with great conservatism.  The difficulty I see here is that we don't have a well defined backwards compatibility target.

In my own project, I have struggled with what to set CMAKE_MINIMUM_VERSION to (a terrible mis-feature if ever there was one).  I had been holding some changes back because I believed I needed to support RHEL / Centos 7 - CMake 2.8.x.  Only recently one of my users on RH7 spoke up and said that my CMake build had long been broken on that platform and he has had to self-install (locally) CMake for a long time.  Progress had been needlessly frozen by a ghost I did not know and was not testing.

In my experience, projects that rely on extremely limited toolchains aren't in a big hurry to update to the latest release of every dependency.  They are generally happy to remain frozen in time with a well tested system that works.

What is the union of esoteric systems stuck on ancient toolchains that also need to update to the latest / greatest FLTK? 

As FLTK moves from 1.3.X to 1.4.X, it is the perfect time to draw some line in the sand.  To determine what will be supported (and hopefully tested) - and what will be allowed to remain at 1.3.X (or earlier).

I don't know where to draw that line -- and I'm not going to argue for any particular feature, compiler, or platform.  However, catering to a vague notion seems unsustainable.  In my own project, I held back changes for compatibility to a platform that didn't even work.

It seems a reasonable first principle would be that we can't claim to support anything that we can't test.  Travis, Jenkins, GitHub Actions, and all the other free/commercial CI platforms I am aware of only support platforms back one or two versions.  They certainly don't support anything exotic or embedded.  From there, it seems reasonable to expect users invested in support of antiquated systems to at least speak up if not volunteer to test on those platforms.

I realize this is very difficult -- many users don't follow these development lists -- but the alternative (supporting unknown vague legacy systems) is impossible.  When faced with impossible, difficult looks pretty good....

Perhaps we need a survey to search this out.  What platforms do users need supported -- and do you have any intention of continuing to update FLTK on those platforms to 1.4.X and beyond?



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-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.