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


I'll bite.

> 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
context requirements.

> - 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_
or a::C.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
ambiguity rule.

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.

Michael C


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