[C++] Attack Plan

[Ben Longbons <brlongbons at gmail dot com>]

Under the assumption that most active gdb maintainers intend that
future gdb releases be written in C++, I am presenting a possible plan
for the conversion, based on my experience with a conversion about
1/5th the size of gdb.

I have found 3.5 areas of discussion, 2.5 of which I have actually written.
- System Requirements
- Attack Plan
-- Warning Header Proposal
- Style Guide (to be written, probably not by me)

A shared editing pad is available at http://piratepad.net/gdb-cxx, it
will contain links to the archived mails so don't be concerned about
editing what I wrote there.

This thread will discuss most of my attack plan.

This is a very rough plan of how to go about converting gdb to C++. As
we get farther through the process, we may encounter other issues.

According to tromey, the scope of the conversion is limited to gdb/,
which makes sense to me. gdb/ is about 500 kLoC excluding
gdb/testsuite/, and I have prior experience doing a C -> C++
conversion and idiomization on 100 kLoC.

Tentative timeline: gdb 7.7 (should have released 3 months ago) will
be C, gdb 7.8 will be C++, gdb 7.9 will be idiomatic C++. Releases are
slightly over 6 months apart.


The first step that must be done is to wrap every appropriate header
in a conditional extern "C". Is there some place in the existing "make
check" machinery that can do (find gdb/ -name '*.h' -exec grep -q
'extern "C"' {} ';') ?
This task is very simple and not controversial, so it could be done by
anyone (including me if that's the most convenient); if header
comments are consistent, it could probably be done entirely via a
script.
This is, however, the one step that needs to be done to files outside
gdb/, so the task of identifying them might not be completely trivial,
I'd need to study the include graph.


The second step is a somewhat controversial proposal to change the way
warnings are handled in development mode, so I split it to a separate
conversation.
I am likely to need some small assistance in doing this; if this stage
is rejected I am likely to need significantly more assistance in other
stages.


The third step is to introduce warnings that are practically required
for development in C++.

The two warnings I consider critical are -Werror=missing-declarations
and -Werror=redundant-decls. Combined, they mean that every global
variable and every function is either declared in a header or is
declared static (I'm not sure exactly which compilers to this right
for variables, but functions are the important thing). This is
important because unlike C, C++ allows function overloading, and would
otherwise let typo'd code compile successfully but fail to link.

You might argue that all *current* code already must have matching
signatures (because C forbids overloading), but a major part of C++
idiomization consists of changing the signature of functions.

Currently, gdb has a number of extern declarations in .c files, which
will need to be hoisted into existing or new headers.

Note that gdb currently uses -Wmissing-prototypes, which covers some
of the same area as -Wmissing-declarations, but is only applicable to
C.

After those two, add -Wc++-compat (even in non-development mode?), but
beware that it does NOT catch most of the issues that will come up.
What we can do is add "-x c++" to the compiler flags using the same
mechanism we used for "-include gdb/warnings.hh"

In the worst case, we may need to have some #ifdef __cplusplus code
until the transition happens. When I converted my codebase, I remember
hitting problems with anonymous unions.

This step is the only "hard" step, and I intend to do all of it.


The fourth step is to actually rename the files from .c to .cc (chosen
over .C, .cpp, .cxx, and .c++ because gcc has already bikeshedded it
and this is one of the few cases where it makes sense to follow them).
git is very intelligent about renames provided nothing else changes in
the file at the moment when it gets renamed, you can even apply a
patch or do a merge across it and it will DTRT as long as you aren't
introducing new files.
For sanity's sake, at this point I suggest that .c files be banned from gdb/
For practical reasons, this step will probably be actually performed
by somebody with full push-without-review permissions, but it is very
simple.

Fifth and finally, I suggest that as the various C APIs are replaced
with C++ APIs, the relevant header be renamed from .h to .hh and the
extern "C" be removed.
This step will be done by any individuals who form the new APIs, which
I intend to help with. From experience, the obvious "s/struct/class/
and change the freestanding functions into member functions" is not
the best approach for all code.


Significantly, note that at no point in this process does development
on gdb have to stop, and other than the "must be declared in a header
or static", has no interaction with the minimum deploy requirements or
the style guide.

Thanks for your time,
Ben Longbons (o11c on IRC)