Moving to C++11 or C++14

[awulkiew]

I'd like to start a discussion about moving to the newer standard. Among other things it would definitely make some of the internals clearer than they are now. What do you think about it?

One solution would be to simply announce that Geometry drops the support for older compilers. We should also decide which C++11 features exactly we'd like to use because the support for different features was added in various versions of different compilers. I prepared a list of the most important features I think we could use and the list of 4 compilers below. I'll update it if someone suggests that additional feature is useful.

The feature I think would be the most useful is auto because it'd allow us to get rid of many very long template instantiations, typedefs, etc. So I marked the features and minimum versions of compilers based on auto feature below (so versions GCC 4.4, Clang 2.9, VS 2010, Intel C++ 11.0 and below). The youngest of these compilers is GCC 4.4 released in March 13, 2012. Of course we can relax it if needed, .e.g Rvalue references would also be useful and they are supported in the same versions besides Intel C++ which needs the next minor version. The next thing is I think lambda expressions but this would require GCC 4.5 and Clang 3.1 which basically means compilers released in and after 2012.

Feature	GCC	Clang	MSC/MSVC/VS	Intel C++
Rvalue references	4.3	2.9	16.0/10.0/2010	11.1
Variadic templates	4.3	2.9	18.0/12.0/2013	12.1
Initializer lists	4.4	3.1	18.0/12.0/2013	13.0
Static assertions	4.3	2.9	16.0/10.0/2010	11.0
auto-typed variables	4.4	2.9	16.0/10.0/2010	11.0
Lambda expressions	4.5	3.1	16.0/10.0/2010	12.0
decltype(expression)	4.3	2.9	16.0/10.0/2010	11.0
Null pointer constant	4.6	2.9	16.0/10.0/2010	12.1
Strongly-typed enums	4.4	2.9	17.0/11.0/2012	13.0
constexpr	4.6	3.1	19.0/14.0/2015	13.0
Delegating constructors	4.7	3.0	18.0/12.0/2013	14.0
Explicit conversion operators	4.5	3.0	18.0/12.0/2013	13.0
Defaulted and deleted functions	4.4	3.0	18.0/12.0/2013	12.0
Range-based for	4.6	3.0	17.0/11.0/2012	13.0
noexcept	4.6	3.0	19.0/14.0/2015	14.0
Type traits	4.3	3.0	14.0/8.0/2005	10.0

See: cppreference, GCC, Clang, MSVC, Intel.

For context release dates of the compilers.

Compiler	Release date
GCC 4.3	Jun 27, 2011
GCC 4.4	March 13, 2012
GCC 4.5	Jul 2, 2012
GCC 4.6	April 12, 2013
GCC 4.7	June 12, 2014
Clang 2.9	April 6, 2011
Clang 3.0	December 1, 2011
Clang 3.1	May 22, 2012
VS 2005	October 2005
VS 2010	April 12, 2010
VS 2012	August 15, 2012
VS 2013	October 17, 2013
VS 2015	July 20, 2015
Intel C++ 10.0	June 5, 2007
Intel C++ 11.0	November 2008
Intel C++ 11.1	June 23, 2009
Intel C++ 12.0	November 7, 2010
Intel C++ 12.1	September 8, 2011
Intel C++ 13.0	September 5, 2012
Intel C++ 14.0	September 4, 2013

[mloskot]

A w e s o m e!

I actually was going to propose it at some point soon and offer help in the code migration.
One thing I'd like to do is to get rid of Boost.TypeTraits and Boost.MPL, replacing the former with <type_traits> and the latter, where necessary`, with Boost.MP11. I did that for Boost.GIL already.

I'd like to help. Please, let me know if/where I can help.

GCC 4.8

IMHO, when moving to C++11, there is little point to support anything older than GCC 4.9. The GCC 4.8 is dead, see boostorg/gil#282 (comment)

[awulkiew]

I was conservative in my proposal to maximize the effect with the least possible change but we can do a bigger jump.

Type-traits wouldn't be a problem since we're nearly there in the initial proposal (need Clang 3.0).

Regarding MP11, I didn't pay much attention, is MP11 much superior than MPL?

I can't find the list of compilers or language features MP11 depends on. I see variadic templates and template aliases in the overview so I guess these features are required. If this is correct it means we'd need at least GCC 4.7(4.9), Clang 3.0, VS 2013 and Intel 12.1 which is not that high requirement.

I'd like to help. Please, let me know if/where I can help.

Well, we have to agree about a set of features and compilers and then you are free to go with proposing anything you like :)

[awulkiew]

There is a short list in the readme at GitHub, so:

• g++ 4.7 or later
• clang++ 3.3 or later
• Visual Studio 2013, 2015, 2017

I wonder what do they need Clang 3.3 for and what about other compilers.

[mloskot]

Type-traits wouldn't be a problem since we're nearly there in the initial proposal (need Clang 3.0).

Often, when you get rid of TypeTraits, you need to get rid of MPL or do some plumbing.

Regarding MP11, I didn't pay much attention, is MP11 much superior than MPL?

Without a doubt. It's simpler, cleaner, faster, easier on compiler.

I can't find the list of compilers or language features MP11 depends on

GCC 4.9 or later (GCC 4.7, 4.8 support is limited).

Talk to @pdimov

I'd like to help. Please, let me know if/where I can help.

Well, we have to agree about a set of features and compilers and then you are free to go with proposing anything you like :)

Sure. Currently, I'm just seeing your proposal as opportunity to make some suggestions here myself, but I since I'm not involved in the core development, I'll follow your lead regarding the requirements.

[awulkiew]

Sure. Currently, I'm just seeing your proposal as opportunity to make some suggestions here myself, but I since I'm not involved in the core development, I'll follow your lead regarding the requirements.

Right, I appreciate your suggestions. I don't have a strong opinion about the minimum versions. I would have nothing against going directly to C++14. C++17 is probably not an option though I'd like to use constexpr if. I'm more concerned about the users. We could ask on the list but I think the majority of users is not subscribed so we have to estimate.

@barendgehrels What do you think about it?

[vissarion]

Thanks @awulkiew for opening this discussion!

I neither have a strong opinion on minimum versions (thanks for the tables above!). It is actually a user issue, maybe @barendgehrels knows more about user needs/costraints.

Also does it make sense to apply the new standard first to new features or move the whole library directly to C++11 (or later) or even support two versions?

[barendgehrels]

Thanks for this. Yes, I think at some point we should move to C++11 or so.

Of course I don't know all users, and I agree that we should ask the list first to see which versions of the language they are using. I know some users which are using C++11 internally - so for them this would be very welcome, but OTOH if we would go to C++14 directly, that would be a big problem: they cannot upgrade Boost anymore. This will be the case for many users.

How are other Boost libraries doing this? Just drop support for C++03, or create a clone, freeze the current version ("geometry") and continue with, for example, Boost.Geometry2 ? Like we discussed in Brussels I think.

Anyway, let's first ask the Geometry list to see if they like the idea, and then the Boost list to see how other libraries are handling this (or maybe you know this already).

[mloskot]

There have been numerous discussions about migrating Boost to newer versions of C++. AFAIK, there is no grand plan in place.

Each library is independent here and maintainers are free to switch their libraries to newer versions, especially libraries which are not core dependencies of other Boost libraries.

One quote from @pdimov that I remembered, https://lists.boost.org/Archives/boost/2018/11/244180.php

much of the outside world thinks of Boost as a single thing.
Our perspective as library maintainers is that libraries are
independent

[awulkiew]

I know some users which are using C++11 internally - so for them this would be very welcome, but OTOH if we would go to C++14 directly, that would be a big problem

I think it's more about specific compilers than a standard because various compilers implement certain sets of features. Standard is theoretical definition of features, compiler version is practical (+compiler bugs). E.g. if they are using GCC 4.9 or later in their company they could use some of the C++14 features already assuming it's not against their guidelines to compile with -std=c++14. But yes, I agree it would be a big jump. Though I'd like to use return type deduction, generic lambdas and variable templates but it would require GCC-5 (2015), Clang-3.4 (2014) or VS 2015 and I think this requirement would be too high. But I'm flexible. ;)

Just drop support for C++03, or create a clone, freeze the current version...

The question is: would significant number of users want to use C++03 Geometry and at the same time other libraries further developed in future versions of Boost? In that case we could consider maintaining both versions of Geometry at the same time and by maintaining I understand making sure it compiles with future versions of other libraries, so no bug fixes or new features. Otherwise we could simply bump the requirements and force users who want to use older Geometry to use older versions of other libraries as well. If really needed these users would be forced to marry new Boost with old Geometry and resolve problems by themselves.

...("geometry") and continue with, for example, Boost.Geometry2 ?

I'd rather freeze the current version as Geometry03, GeometryOld or something like that and simply move forward with Geometry (like SpiritClassic and Spirit).

[mloskot]

To me, Spirit Classic is different as it's a maintained line of 1.8.x to some extent.
So, it's not frozen version.
Do you expect to maintain the two lines of Geometry?

Isn't it enough to freeze implicitly via Boost release?
For example,

• Geometry in Boost <= 1.75 is C++03
• Geometry since 1.75 requires C++11 compiler

I'd argue that it's important to label library with minimal required C++ standard version rather than relying on selection of C++ features.
The latter would open the library for mixture of features from different C++ versions - quite a mess, especially from user point of view.

[awulkiew]

Do you expect to maintain the two lines of Geometry?

If really necessary but I'd prefer to avoid that.

Isn't it enough to freeze implicitly via Boost release?

I have nothing against it. :)

The latter would open the library for mixture of features from different C++ versions - quite a mess, especially from user point of view.

I agree. The features mentioned here are only for us to decide what we'd like to do. In addition to explicitly stating that we require C++11 (but only as general requirement) I'd suggest explicitly labeling library by specific versions of compilers. This way from user perspective everything would be even more clear since they wouldn't have to know which version supports all features from the standard and at the same time we would be able to pick earlier version than the one supporting all features if we didn't need all of them. Just like MP11 depending on GCC 4.7. Yes I know the support is partial but maybe we don't need all of it.

Furthermore if we agreed to your suggestion about GCC 4.9 we would still have to state this compiler version is required because technically all C++11 features were implemented in GCC 4.8.1. So there is no running from compiler versions supporting features in ways satisfying our needs.

Compiler version is more practical than C++11 standard.

[barendgehrels]

AFAIK, there is no grand plan in place.

I know, and I know we can decide for our own - but what happened in practice for other libraries?

I think it's more about specific compilers than a standard
Compiler version is more practical than C++11 standard.

Of course compilers are important, but they follow a standard and users usually follow a standard. The standard is specified in makefiles / when compiling. Organizations where I've worked for are often flexibel in compilers (some use clang, some use gcc - for some OS you use other compilers, with the same codebase) but are not flexibel in standard. And indeed sometimes only a specific subset of C++11 features are allowed to be used, to still support some older versions of compilers.

assuming it's not against their guidelines to compile with -std=c++14

I'm talking about large organizations, with 100s of developers on one codebase. They prepare these upgrades for months. You cannot specify a new standard overnight without breaking several things at the same time. The same, indeed, holds for compilers versions.

I'd rather freeze the current version as Geometry03

Good idea, I would prefer that indeed over Geometry2 - besides that, freezing a library would be an option for me personally - but I don't know if that holds for all our users. The drawback of renaming the current version is that current users have to adapt their includes, so it still requires some effort for them.

Do you expect to maintain the two lines of Geometry?

Complete maintenance will require too much effort. But just porting some obvious bugs on request might be an option. Therefore I would prefer to upgrade after all rescaling has been removed. That takes me quite some time already, sorry for that, but the end is visible now.

[mloskot]

@barendgehrels

AFAIK, there is no grand plan in place.

I know, and I know we can decide for our own - but what happened in practice for other libraries?

Approaches are different. For example

• coroutine is C++03 and coroutine2 is C++11

• GIL since Boost 1.68 requires C++11 and there is no GIL2 or GIL3. The README just says which Boost version is required now and which for old compiler. Obviously, GIL from Boost <1.68 does not offer new features that are being added to GIL in Boost >=1.68.

There are libraries that require C++11 or C++14 since their beginning.

@awulkiew

if we agreed to your suggestion about GCC 4.9 we would still have to state this compiler version
is required because technically all C++11 features were implemented in GCC 4.8.1.

Yes. What I'm trying to explain is that even you pin at GCC 4.8 based on the list of C++ features it supports, you may be forced to remove 4.8 from the list because some features will simply not work due to bugs. Those bugs in the GCC 4.8 and other old compilers/versions will not be fixed.

[barendgehrels]

@mloskot thank you!

[vissarion]

I lean against @mloskot's proposal about supporting a minimal required C++ standard version. Then we can also comment on how this is implemented in various compilers, to help users.