Re: Will therefore GDB utilize C++ or not?

[Yao Qi <yao at codesourcery dot com>]

On 04/05/2012 04:47 AM, Tom Tromey wrote:
> My concrete transition proposal is:
> 

I went through discussions in this thread, and go back to read Tom's
proposal again.  Get some additional thoughts, maybe, we can start from
something easy and less-controvesy,

> 1. Modify GDB so it can be compiled with -Wc++-compat.
>    This would be the first patch series.  There is already an archer
>    branch for this.
> 

Modify GDB as well as GDBserver/IPA so they can be compiled with
-Wc++-compat.

> 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is
>    not complete).  This would be the second patch series.
> 

Change to use C++ compiler to compile GDB, GDBserver and IPA.  If this
is too aggressive, we can use C++ compiler to compile GDB and keep C
compiler to compiler GDBserver and IPA.  Sources in gdb/common/ will be
compiled by C compiler and C++ compiler respectively.  Is it possible?

> 3. Require C++.

Then, we can require C++ for GDB and keep GDBserver and IPA unchanged.

> 
> 4. Change selected modules to use C++ rather than C.
>    I don't think a wholesale change makes sense, but some areas would
>    benefit.
> 
>    My first target would be to change the exception handling system to
>    use C++ exceptions.  This would enable us to begin using RAII in
>    some areas, which would help robustness.
> 
>    My concrete plan here is:
> 
>    * Use the GCC cleanup-checking plugin I already wrote to detect
>      cleanup-aware functions.
> 
>    * Modify these functions, using a script, to add an RAII-using
>      object to manage the local cleanups.  This is important so that
>      we run cleanups at the correct time during stack unwinding.
> 
>    * Change throw_exception to use 'throw' and all TRY_EXCEPT
>      instances to try...catch.
> 
>    * Finally, convert functions to static RAII usage when appropriate;
>      this will be an ongoing transition.

Most of the objections are to these points.  We can postpone them, and ....

> 
>    I think our second target will be sorting out Python reference
>    counting, so we can avoid the many problems we have had there.

... start this first, if this is quite isolated and not dependent on #4
above.  Python reference counting will not be used in GDBserver, so we
don't have to worry about GDB/GDBserver code sharing.

-- 
Yao (éå)