This is the mail archive of the gdb@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: Move GDB to C++ ?


Stan Shebs wrote:

> As many know, there is a project afoot to investigate the recoding of
> GCC from C into C++. I believe the C++ idea was briefly touched on for
> GDB at the summit, although I don't remember much discussion. Anyway,
> this would be a good time to start thinking about it, and if people are
> generally in favor of the idea, we can start small by tweaking the
> sources to be C++-friendly, avoiding keywords and so forth; GCC has a
> new warning flag -Wcxx-compat that can help.
> 
> For my part, I think we should do it. GDB has quite a bit of object-like
> structure internally, and while in the past it was taking a bit of a
> chance to rely on the availability and reliability of C++ compilers,
> those concerns are now generally outdated; I'm not sure any of the
> potential problem hosts are even supported any longer.


I think this discussion went a bit wrong way -- trying to convince folks that
*investing effort* in converting to C++ is justified. However, I don't think
the proposal is about making folks not interested in C++ doing any work -- the
proposal is about allowing folks who do some specific work, and want to make
use of additional features C++ provides, to use those features, while not imposing
significant problems on the rest of contributors.

Let me give an example. I believe that using C++ in varobj.c would allow to reduce
the amount of code; so should I need to add new "method" to varobj, I'd like to convert
from current emulation of classes to C++ classes. The only folks who actively touch
that file are Nick and myself. Assume Nick does not mind. Then, why not allow me to
use C++ for that module? Some possible reasons:

1. It would require having C++ compiler when building GDB. This, of course, maybe
be issue for companies who provide GDB on exotic platforms. The issue can be discussed,
or it can be discarded on the ground that this is list for FSF GDB, and FSF makes gcc
as well.
2. Not everybody knows C++, so if I'm hit by a bus, not everybody will be able to
adopt this module. (This is obviously more important for core parts than for MI).
I'm not sure if this aspect is critical -- I get the impression that even those
who object to C++ actually knows the language.
3. Misusing C++ features can make the code totally unmaintainable. However, misusing C
can have the same effect. As all patches are posted, anybody can object when such
misuse of C++ features happens. The same mechanism can be used to object to C++ features
not universally known to GDB developers.

So, it seems to me that there is a group of people that will benefit from switch to C++,
and the inconvenience for people not willing to invest any time into this project will
be minimal. Sounds like an overall gain, no?

- Volodya



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