This is the mail archive of the
mailing list for the GDB project.
Re: C++ nested classes, namespaces, structs, and compound statements
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gdb at sources dot redhat dot com, jimb at redhat dot com
- Cc: bkoz at redhat dot com, dan at dberlin dot org
- Date: Sat, 6 Apr 2002 00:02:42 -0600
- Subject: Re: C++ nested classes, namespaces, structs, and compound statements
> In summary, the data structure GDB needs to represent C++ structs
> (classes, unions, whatever) has a lot of similarities to the structure
> GDB needs to represent the local variables of a compound statement.
Sounds reasonable to me.
It also sounds dangerous. It's true that namespaces, structs,
and compound statements are all identifier binding contexts.
But if you start treating a struct as a type of compound statement
you could get into a maze of twisty forced meanings. You have to
reach down and create a new paradigm and then port both structs
and compound statements to it.
Think about how much context information an identifier-binding-object
needs to do its job. I think it would be difficult to come up with a
universal context object that both structs and compound statements
can use. Each identifier-binding-object has its own specialized
> - And what about ambiguous member names?
The C++ language spec says: if class A inherits from both class B and
class C, and both B and C have a member "foo_", then an unqualified
reference to a.foo_ is illegal. The programmer has to say a::B.foo_
The last time I checked, gdb just grabs one of the a.foo_ values and
uses it. I think it would be a lot better for gdb to enforce the
What happens right now if 10 C source files have a static variable
named "i" and I say "print i" and I am not in any of those source
files at the moment? What *should* happen?
It's late ... I'm rambling.