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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
> If you asked me not too long ago, I'd have been strongly in favor
> of C++.  However, that is no longer the case.  I'm now pending
> towards "no C++".

I have re-read now the thread and I have not found any blocker issues left.

Here is a plan that should IMHO satisfy all the requirements stated here.
I did not reply to C++ disagreements which were already well enough replied
here.


Current gdbserver will be also in C++.

For most embedded Linux kernel targets it will be enough to build the standard
fully featured gdbserver with static libstdc++ (making it only ~2x larger).

There will be also separate minimal gdbserver in plain C.  For some very
minimal targets still running Linux kernel but no longer having C++-capable
compiler or having some other problem running C++.  There was stated no
concrete such target but maybe there exists one.  This minimal server has no
need for non-stop/multi-inferior etc., it will be created by stripping down
the current one; but in fact one can be also easily code it from scratch.

libinproctrace.so will remain in C so far.  I do not think this sole reason
should block the GDB + gdbserver move to C++.  In the future I believe it can
move to statically built libstdc++ without problem.  It will never be
supported on the minimal C gdbserver which also is not a problem.


There should be provided a list of systems GDB needs to remain compatible with
and which are available for login directly or which can be at least promptly
regression tested upon request.  As could be seen for example on Solaris
recently the compatibility with a system which GDB is not tested against will
break.  The compatibility is not kept automatically just thanks to the reviews.

Then we can find out the minimal C++ level can be required.  I assume some
-std=c++98 with a bundled subset of Boost should be OK.


Thanks,
Jan