Moving to C++11

Moving to C++11

[Nicholas Krause]

Greetings Jonathan and Jason,

I was wondering what work is required to move to C++11. Seems your

both interested in getting this done and so am I. Perhaps we start

similar to Git with a wiki page about what features would be useful

and then start migrating the makefiles to allow for this.

So far according to the previous discussion it seems that the community

would like these features:

1. Template Aliases

2. Better narrowing supprot for core types

2. Auto for local variables

3. std::move,rvalues

4. For each loops

Let me know if I missed something but I will be glad to help out with this,

Nick

PING:Re: Moving to C++11

[Nicholas Krause]

On 9/30/19 1:50 PM, Nicholas Krause wrote:
> Greetings Jonathan and Jason,
>
> I was wondering what work is required to move to C++11. Seems your
>
> both interested in getting this done and so am I. Perhaps we start
>
> similar to Git with a wiki page about what features would be useful
>
> and then start migrating the makefiles to allow for this.
>
> So far according to the previous discussion it seems that the community
>
> would like these features:
>
> 1. Template Aliases
>
> 2. Better narrowing supprot for core types
>
> 2. Auto for local variables
>
> 3. std::move,rvalues
>
> 4. For each loops
>
> Let me know if I missed something but I will be glad to help out with 
> this,
>
> Nick
>
> Just pinging this as I've not heard any replies.
Nick

Moving to C++11

[Nicholas Krause]

Greetings David,

I posted on the list about moving to C++11/C11 but the focus was on

C++11 for my work. Seems that other people wanted to use some

parts of the C++11 standard including rvalues,move,auto and template

aliases. The thread is here:

https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html

I've come to the conclusion that enabling parts of it would be useful 
overall based

on the linked discussion.

Therefore I'm opening up the discussion again with the commitee involved 
to figure

out what should be used and how the migration should take place,

Nick

Re: Moving to C++11

[Eric Gallager]

On 9/26/19, Nicholas Krause <xerofoify@gmail.com> 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.

Re: Moving to C++11

[Pedro Alves]

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

Re: Moving to C++11

[Richard Sandiford]

Tom Tromey <tom@tromey.com> writes:
>>>>>> "Jason" == Jason Merrill <jason@redhat.com> 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

Re: Moving to C++11

[Tom Tromey]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> 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

Re: Moving to C++11

[Jason Merrill]

On Thu, Sep 26, 2019 at 4:08 AM Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> 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

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 <jwakely.gcc@gmail.com> wrote:
>> On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> 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.

Re: Moving to C++11

[Richard Biener]

On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> 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.

Re: Moving to C++11

[Jonathan Wakely]

On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> 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.

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