C++11 Version?

[AKJ7]

Why is the mininum C++ requirement C++11?

[JohelEGP]

The "About" at https://github.com/ericniebler/range-v3/ reads

Range library for C++14/17/20, basis for C++20's std::ranges

This library has required at least C++14 for a while now.

[AKJ7]

Why?

[AKJ7]

C++11 remains the most used C++ version. Allowing those limited to a C++11 compiler to use the library would be nice.

[ericniebler]

C++11 doesn't have variable templates, which are needed by the concepts emulation layer. I will not be adding back support for C++11.

[RokerHRO]

If variable templates are the only C++14 feature you're using, they can be replaced by static variables of class templates. (That even works in C++98.) But the primary question is: Which platform comes today with a C++ compiler that does not support C++14? Is that platform important enough to accept those hacks? AFAIK today (end of 2020) the IBM XL C/C++ compiler for z/OS is a bit behind and still supports only C++11. That's why I am limited to C++11 on my company's projects. But the C++14 features I'm using are rare and can be emulated – via #if __cplusplus < … – by their boost equivalents quite well. :-)

[AKJ7]

The whole Arduino platform for example is limited to C++11 by default, even if the controller provides a C++. The embedded system world itself moves very slowly and C++11/C99 is considered to be the norm. Why not go the extra effort and add C++11 support? I mean modern C++ starts from there. I plan to add C++11 support to this library when i have time.

[keryell]

@AKJ7 if you really want to have an impact on the community, what about working on having C++20 available on Arduino instead of leaving this community with some JurassiC++? It will solve this problem but also a lot of other problems. I do not want any neuron from @ericniebler being distracted by supporting obsolete C++ version instead of defining the range library for C++23 and later. Unfortunately, at the end there is only a limited amount of valuable resources... :-(

[AKJ7]

@keryell, i used Arduino as an example. I suppose there needs to be advancements and we should move on, but we don't always have control over the compiler or hardware that is provided. For example, asking the Arduino (platform, because other controllers use its tools too), which tries to make programming as simple as it can, to allow mutiple C++ versions, for every controller they support, for every library! This would take ages. I found a mistake in a schematic of an Arduino WIFI module, reported it, the report was acknowledge a year later and till now nothing was changed.

As there are implementations of std:optional, std::variant, std::filesystem, ... for C++11, i thought the same would apply here.

[cjdb]

As there are implementations of std:optional, std::variant, std::filesystem, ... for C++11, i thought the same would apply here.

That only applies if a library maintainer is willing to put the effort into supporting it, which @ericniebler has clearly stated he's not interested in doing.

[RokerHRO]

@AKJ7 : I'd say, just try to make a branch/fork of range-v3, that would only need C++11 and we'll see how big the impact would be. In my C++ code I put all this things in a single config.hh header that contains a lot of stuff like this:

#if (__cplusplus >= 201606)  // std::string_view is C++17.
#   include <string_view>
    typedef std::string_view StringView;

#else // in C++11 / C++14 use boost::string_view instead.
#   include <boost/utility/string_view.hpp>
    typedef boost::string_view StringView;
    // some additional stuff that is missed in boost::string_view
    // …
#endif

and also switches for C++11 vs. 14.

If this will be small and handy we might convince the upstream maintainer to integrate it in range-v3. If not, you still can offer it as fork/patch of the original range-v3 sources.

[keryell]

I understand the short term motivations for this old C++ support. Globally, the situation is painful. But for having worked in a few embedded system companies or hardware companies, often these compiler and language choices are made for opportunist reasons, by ignorance or politics, by people not involved in real C++ programming or healing their PTSD with C++ from the 90's... :-( And this is sad if at the end it dilutes the whole C++ range effort. On the other hand, if Arduino is serious about C++ and simplicity, they should move on C++20 and put all their extensions into C++ library instead of some kind of JurassiC++. And good news, @cjdb in this discussion leads the ISO C++ SG20 working group about teaching C++ and making C++ simpler... :-) Otherwise, it is always possible to buy/use another platform, work in another company, etc. I agree that the difficulty is to make the decision makers aware of this situation... Good luck!

[zhe62]

Not sure if it is good idea to use C++20 for Arduino, given the limited SRAM and flash size, even though personally I wish range-v3 can used used in such applications

[AKJ7]

@zhe62 i used the Arduino Platform as an example. Like i said previously, modern C++ starts at C++11 and most libraries do their best, usually to adhere to it (Boost, Asio, filessystem, expected, ...).

I guess it doesn't matter anyways.