Go C++11? (was: Re: [RFA 09/22] Remove make_cleanup_restore_current_ui)

[Pedro Alves <palves at redhat dot com>]

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.

Thanks,
Pedro Alves