This is the mail archive of the gcc@gcc.gnu.org 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 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


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