Re: Go C++11?

[Luis Machado <lgustavo at codesourcery dot com>]

On 10/17/2016 06:43 PM, Pedro Alves wrote:
> On 10/13/2016 04:43 PM, Pedro Alves wrote:
> > On 10/13/2016 04:19 PM, Eli Zaretskii wrote:
> > > > Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org
> >
> > > > All I know right now that we sorely need an owning smart pointer.
> > > > And for this particular case, I think it makes a ton of sense to go
> > > > dual dialect.
> > >
> > > But if we agree to require C++11 starting from now, you can go ahead
> > > with your patch, and don't even need the other dialect.  So this
> > > sounds like a win-win solution to me.
> >
> > Well, that'd be perfect.
> >
> > But as I mentioned elsewhere, I'd prefer to take a staged approach
> > to C++11.  I.e., have a fallback plan.  My shim would actually _help_
> > with that.  So the plan would span a few weeks, and it'd be:
> >
> > #1 - get gdb::unique_ptr in
> >
> > #2 - start using unique_ptr throughout (there's a ton of work
> >      to do here, and it go on in parallel with the remainder
> >      of the plan.)
> >
> > #3 - install the patch that switches C++11 on if the compiler supports it.
> >      The one I sent yesterday.
> >
> > #4 - see if that causes problems.  fix problems.  maybe revert patch
> >      from step #3 if problems are hard to solve quickly.
> >
> > #5 - flip to consider C++11 mandatory.  Make configure error out
> >      if no C++11 compiler is found.
> >
> > #6 - see what workflows break (e.g., see if we need to do anything
> >      with some buildslaves.
> >
> > #6.a - if $problem, revert patch from step #5.  fix whatever workflows,
> >        and goto #5.
> >
> > #7 - otherwise, after some period, start using C++11 in full.
> >      Remove the shim and do s/gdb::unique_ptr/std::unique_ptr/g
> >      throughout the code base.
> >
> > All the while between #1 and #7, we can progressively convert
> > cleanups to use gdb::unique_ptr.  Ie., we'd pipeline/paralyze
> > the work.
>
> So from the analysis I did at [1] it seems like we're actually
> clear from the buildslave's side on requiring C++11.  I thought
> it take longer to update the buildslaves, but MarkW was quick
> and there doesn't seem to be other buildslaves that need
> updating.
>
> Sooo....  Shall we proceed with the straw man proposal and
> apply the patches at [2] (enable -std=gnu+11 on gcc >= 4.8)?
>
>  [1] - https://sourceware.org/ml/gdb-patches/2016-10/msg00496.html
>  [2] - https://sourceware.org/ml/gdb-patches/2016-10/msg00336.html
>
> Do people feel this hasn't been sufficiently discussed?
>
> If we can do this now, I'll happily drop my shim in favor of
> jumping to C++11 quicker!  Maybe it'll find a home in gcc.  :-)
>
> I'd love to hear feedback.

I personally feel this hasn't been discussed much, but honestly it 
doesn't feel like discussion is going to change anything here other than 
create clashes of ideas. :-)

I've seen this go from "You got it wrong. We're not going to move to 
C++11" to "So, shall we move now?" rather quickly. Nothing showed up in 
gdb@ either.

Since we're already moving things quickly, we should probably discuss a 
policy to accept the next standard version and follow that from now on.

My $0.02.