This is the mail archive of the gdb@sources.redhat.com 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: C++ nested classes, namespaces, structs, and compound statements


On Mon, Apr 08, 2002 at 07:02:58PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > GDB already does a great deal of this by the very simple method of
> > using fully qualified names.  It's served us remarkably well, although
> > of course we're hitting its limits now.  But let's not be too quick to
> > discard that approach, for the present at least.
> 
> Oh dear.  I think that's exactly what I'm proposing we replace.  As
> Per said:

> In that situation, we can look up things like `B2::A2::x' in a
> straightforward way: look up B2, look up A2 there, and look up x
> there.  With a symbol table full of fully qualified names, how do we
> do this?
> 
> Can you talk more about why we shouldn't evolve away from placing
> fully qualified names in the symbol table directly, and towards
> representing them more explicitly?

Let me be a little clearer on what I wanted to say there:  I agree
completely that your approach is cleaner, more efficient, more
adaptable, more useful, and generally better than what we have now. 
But let me put my cynic's cap on for a moment and point out some
problems.  I'd love to see us just decide to overcome them all, and I
think it's viable, but we need to make sure we consider them first.

The "incremental change" Problem

  Could we write the necessary wrapper functions to simulate lookup of
a fully qualified name and use them everywhere we haven't changed yet? 
Probably a non-issue.  How much will have to be changed at first to
make this functional?  For instance, all the debug readers would be
substantially affected.

The "big change" Problem

  There's plenty of places in GDB that assume the current name lookup
behavior.  We'd have to do a lot of digging to make sure we did scoped
lookups everywhere that needed them.  On the upside, we could use this
as an excuse for some really rocking test coverage improvements.

The "debug info" Problem

  DWARF-2 gives us enough information for this.  Sun's stabs extensions
(well, recent definitions; it being their format and all) also give us
enough information.  HP's stuff probably does, but I don't know if
we've got anyone that knows it well enough to update.  For most other
formats, we'd just have to fake it as well as we could and hope for the
best.  Look at the debugging output GCC 3.0 / -gstabs+ puts out for
namespaces or even nested classes sometime.


I'm sure I had another in mind, but it slips my mind at the moment. 
For debug info, we could probably add a 'unknown_scope_kind' to the
enum name_kind I described in my other message, and change all
periods/colons etc. into those.  For free, this hierarchy would let us
associate out-of-line member function definitions directly with the
types, which would make my life in C++-land much nicer!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


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