This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving to C++11

On 9/26/19 4:08 AM, Richard Biener wrote:
On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <> wrote:
On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <> wrote:

I asked about moving to C/C++ 11 as it would make it easier to

allow multithreading support due to having a memory model

alongside other features. Jason Merill mentioned due to it

being so common it may be a good  time to.

Moving to git seems to be universally agree on so I'm opening the discussion

for the same as related to C/C++11 migration and if possible opening

a TODO similar to git if decided on.

Please post your comments or ideas about the migration in response to this


For a start, it doesn't make sense to talk about C/C++11.

C and C++ are separate languages, and so are C11 and C++11. There is
no reason why using C++11 should imply using C11, let's not confuse

GCC is written in C++ so the topic should be C++11.
Note the main issue is host compiler support.  I'm not sure if C++11 would
be the step we'd gain most - for some hashtable issues I'd have needed
std::move support for example.  There's always the possibility to
require an intermediate step (first build GCC 5, with that you can build
trunk, etc.), a install.texi clarification could be useful here (or even
some automation via a contrib/ script).
I agree.

I'm not too worried about requiring even a C++14 compiler, for the
set of products we still release latest compilers we have newer
GCCs available we can use for building them (even if those are
not our primary supported compilers which would limit us to
GCC 4.8).
Note I'd still not like to see more C++ feature creep into general
non-container/infrastructure code, C++ is complex enough as-is.

While the features that  seem to be the most useful to use I will

list below:

1. C++ memory model and atomics classes

2. Move and R values

3. Auto?

4. For each loops may be nice i.e. x: array loops through all of the array

To your point it seems that the above are the most useful and we can

just avoid the others as these don't really affect core code and even

if they do its an extension rather of older features. Auto is just

templates for variables really.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]