What C++11 features are allowed in FLTK?

[Manolo]

I had understood std::string and std::vector<type> were the only 

C++11 features allowed in FLTK 1.5

That's what says

   https://www.fltk.org/newsgroups.php?s61+gfltk.coredev+v22361+T0

But std::shared_ptr and std::mutex have creeped in.

This prevents building FLTK 1.5 for the i386 architecture under macOS.

[melcher....@googlemail.com]

Hi Manolo and others,

my understanding is this: 

1: we limit ourselves to C++11 for everything we do inside the library. 

Rationale: Pretty much anything C++11 is fine, as long's we don't end in a huge template mess, just because we can. We want to use C++11 wisely where it makes life easier for the developers. Yes, we will loose support for some very old systems (per the name, this should be limited to things before 2011), but FLTK 1.4 is alive and well for those users.

2: we don't want any(?) / much(?) / templates(?) C++11 in the API, or at least have an old style alternative.

Rationale: we want to stick with Fast and Light, and we acknowledge that FLTK shines as a library with many language bindings (Rust, Lua, Ruby, Python, ...). If we go full steam C++ templates, we loose all those users. If we don't add "modern" APIs, we will not get "modern" users.

Comment: there is no perfect solution. FLTK is old, really old, and we must find a balance between keeping those users who love FLTK for having such a simple "C with classes" interface, and this users who want to use everything that C++ has to offer. 

 It's always a bit of an edge case, because how do we handle even the easy stuff Fl_Widget::label(const char*)/copy_label()? Should we add std::string& ? How about string_view? How about optionally std::u8string and std::u8filename at some point? Must we really offer 4 variants of a single call that sets a string, and another 3 variants for reading it back?

For me as a core developer, I am tired of reimplementing C++11 stuff in C98 compatible ways. I would have preferred to go to C++17 or even C++20, but I understand that we will probably never be very attractive to young developers anyway. C++11 is a bearable compromise. And I do understand the perceived fear of templates in the API.

 - Matthias

[Bill Spitzak]

I think string_view can be used, if there is an emulation added to the header files for systems that don't have it. The emulation can be pretty tiny.

I recommend then that any api that takes a string takes only a string_view by value. Functions that return strings return a reference to a const std::string if at all possible.

This probably means it always acts like copy_label is done and strings are stored internally as std::string.

--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkcoredev/a1ad0725-7ffd-4a63-9f86-7413d41e1eaen%40googlegroups.com.

[Greg Ercolano]

On 10/22/25 04:12, 'melcher....@googlemail.com' via fltk.coredev wrote:

2: we don't want any(?) / much(?) / templates(?) C++11 in the API, or at least have an old style alternative.

Rationale: we want to stick with Fast and Light, and we acknowledge that FLTK shines as a library with many language bindings (Rust, Lua, Ruby, Python, ...). If we go full steam C++ templates, we loose all those users. If we don't add "modern" APIs, we will not get "modern" users.

Comment: there is no perfect solution.

Here's a thought, just to explore an idea:

Assuming we really were motivated to provide templates through the API, and let me emphasize I don't think we are, or should be,  but just to explore the possibility..

We probably could provide those modern users with alternate include files that provide templates thru the API, e.g.

• #include <FL/Fl_Box>    // access FLTK internals as templates (instead of #include <FL/Fl_Box.H>)
• #include <FL/Fl_Box.HH> // ditto

C++ uses no .h extension on "modern" includes, hence that first form.
Or if we really need special filename extensions for some reason (doxygen, cmake, etc), we could make up our own, e.g. ".HH"

Neither technique would involve re-implementing entire widget APIs - that'd be crazy. These files might just be two line files that just #define a macro and #includes the normal .H file, the macro setting would enable the "modern" methods via #ifdefs, similar to how our ABI macros enable ABI breaking features.

Anyway, just a thought. I'm not seriously considering this; any programmer choosing to use FLTK should really not expect "modern", and we might not want to even try to attract those kind of "modern" users, as means of "staying in our lane", which has served fltk 1.x pretty well, honestly.

[melcher....@googlemail.com]

Nice idea! I'd suggest `#include <FL/Box>`, but since we don't go there anyway. I have not found much of a use case for templates in out library.

There is one thing that I am working on: allow std::function for callbacks which in turn gives us std::bind to call non-static methods in classes and lambdas with captures, so you can give any number of parameters type-safe to the callback.