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: GDB in C++


Robert Dewar wrote (in part):
> What is needed is an argument that the advantages outweigh
> the disadvantages. Arguments based solely on the value of
> the resulting style improvements are inadequate for me
> unless framed in these terms.

Although I am sympathetic to the idea of re-implementing GDB in C++,
and have mentioned this to Mike Eager off-list, perhaps it would
be worth understanding why this change is being recommended now,
and why it has been recommended previously.  Based on my experience
working on GDB, I relate the suggestion to re-implement GDB in C++
to the suggestion that the internal documentation be improved.  I think
that both suggestions are motivated by the desire to make it is easier
to understand GDB's source code, and to modify and improve it.
In the long run, anything that makes GDB easier to understand and
to improve will lead to a faster pace of development,
and likely improvements in usability and reliability.

If we agree that making GDB easier to understand and to change are
worthwhile goals, then perhaps the discussion should focus on what
are the best and least expensive (in time, effort, and impact
on reliability) methods for achieving those goals?  I think that one
of the appeals of recasting some of GDB's internal object-like
constructs into C++, using a C++ object-oriented style is that this
activity is seen as something that a small group of individuals
can do in a reasonable amount of time and that it might result in
an infrastructure that is easier to understand and to extend.  Further,
there may be reliability improvements because C++ will better enforce
the object-oriented constraints.

If C++ isn't the answer, and keeping all of GDB in "C" is a fixed
point, what changes would the developers recommend that would
offer similar (perceived) improvements in understandability
and extensibility?


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