This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: [RFA 09/22] Remove make_cleanup_restore_current_ui


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.

> The only other thing we need to agree is that we are not going to
> switch to a C++ standard newer than C++11, and won't allow code that
> doesn't compile with C++11 compilers, until the oldest compiler which
> supports that newer standard is at least 3 years old (like GCC 4.8.1
> is today).

Agreed.

> Does this sound like a compromise everyone can live with?

Thanks,
Pedro Alves


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