Moving to C++11

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving to C++11

Nicholas Krause
Greetings,

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

email,

Nick

Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Jonathan Wakely-4
On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <[hidden email]> wrote:

>
> Greetings,
>
> 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
>
> email,



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
things.

GCC is written in C++ so the topic should be C++11.
Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Richard Biener-2
On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <[hidden email]> wrote:

>
> On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <[hidden email]> wrote:
> >
> > Greetings,
> >
> > 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
> >
> > email,
>
>
>
> 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
> things.
>
> 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'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.

Richard.
Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Nicholas Krause

On 9/26/19 4:08 AM, Richard Biener wrote:

> On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <[hidden email]> wrote:
>> On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <[hidden email]> wrote:
>>> Greetings,
>>>
>>> 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
>>>
>>> email,
>>
>>
>> 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
>> things.
>>
>> 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.

Nick


>
> Richard.
Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Jason Merrill
In reply to this post by Richard Biener-2
On Thu, Sep 26, 2019 at 4:08 AM Richard Biener
<[hidden email]> wrote:

> On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <[hidden email]> wrote:
> > On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <[hidden email]> wrote:
> > >
> > > Greetings,
> > >
> > > 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
> > >
> > > email,
> >
> >
> >
> > 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
> > things.
> >
> > 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).

Note that std::move is from C++11.

> 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).

I wouldn't object to C++14, but there's nothing in there I
particularly want to use, so it seems unnecessary.

> Note I'd still not like to see more C++ feature creep into general
> non-container/infrastructure code, C++ is complex enough as-is.

I agree for rvalue references.  I want to start using C++11 'auto' in
local variable declarations.

Jason

Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Tom Tromey-2
>>>>> "Jason" == Jason Merrill <[hidden email]> writes:

Jason> Note that std::move is from C++11.

>> 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).

Jason> I wouldn't object to C++14, but there's nothing in there I
Jason> particularly want to use, so it seems unnecessary.

>> Note I'd still not like to see more C++ feature creep into general
>> non-container/infrastructure code, C++ is complex enough as-is.

Jason> I agree for rvalue references.  I want to start using C++11 'auto' in
Jason> local variable declarations.

FWIW in gdb we went with C++11, because it was the version that offered
the most useful upgrades -- for me those was mainly move and foreach,
but 'auto' is sometimes nice as well.

Tom
Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Richard Sandiford-9
Tom Tromey <[hidden email]> writes:

>>>>>> "Jason" == Jason Merrill <[hidden email]> writes:
>
> Jason> Note that std::move is from C++11.
>
>>> 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).
>
> Jason> I wouldn't object to C++14, but there's nothing in there I
> Jason> particularly want to use, so it seems unnecessary.
>
>>> Note I'd still not like to see more C++ feature creep into general
>>> non-container/infrastructure code, C++ is complex enough as-is.
>
> Jason> I agree for rvalue references.  I want to start using C++11 'auto' in
> Jason> local variable declarations.
>
> FWIW in gdb we went with C++11, because it was the version that offered
> the most useful upgrades -- for me those was mainly move and foreach,
> but 'auto' is sometimes nice as well.

FWIW, on top of what's already been mentioned:

- "= default" would be very useful for some of the core types

- explicit conversion operators would avoid dangerous implicit conversions
  to things like bool.  E.g. it should be safe to provide an explicit
  operator bool() for poly_int and avoid those pesky known_eq (..., 0)/
  maybe_ne (..., 0) conditions

- templated type aliases would simplify wide_int

Richard
Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Pedro Alves-7
In reply to this post by Richard Biener-2
On 9/26/19 9:08 AM, Richard Biener wrote:

> 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'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).

FWIW, GDB requires C++11 nowadays, and the baseline required
GCC version is GCC 4.8.1.  The current policy is here:

https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F

Pasted for convenience:

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 When is GDB going to start requiring C++NN ?

 Our general policy is to wait until the oldest compiler that
 supports C++NN is at least 3 years old.

 Rationale: We want to ensure reasonably widespread compiler
 availability, to lower barrier of entry to GDB contributions,
 and to make it easy for users to easily build new GDB on currently
 supported stable distributions themselves. 3 years should be sufficient
 for latest stable releases of distributions to include a compiler
 for the standard, and/or for new compilers to appear as easily
 installable optional packages. Requiring everyone to build a compiler
 first before building GDB, which would happen if we required a
 too-new compiler, would cause too much inconvenience.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That was decided 3 years ago, so I guess we'd be good for a
reevaluation, though I don't particularly miss C++14 features
all that much, so I wouldn't mind staying with C++11 for a while
longer in GDB.  But if GCC jumps to C++14, I think GDB would
follow along.  Just FYI.

C++03 -> C++11 makes a great difference.  Particularly
std::move and rvalue references are a game changer.

Thanks,
Pedro Alves

Reply | Threaded
Open this post in threaded view
|

Re: Moving to C++11

Eric Gallager
In reply to this post by Nicholas Krause
On 9/26/19, Nicholas Krause <[hidden email]> wrote:

> Greetings,
>
> 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
>
> email,
>
> Nick
>
>

A good first step would be to flip the switch from -Wno-narrowing to
-Wnarrowing in the warning flags GCC uses when building, as C++11 has
stricter rules about narrowing conversions. This would be useful even
if we don't end up going to C++11 yet, as such narrowing conversions
are bad even in versions of the standard where they're allowed.