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



Daniel Jacobowitz <drow@mvista.com> writes:
> > > Doing it for struct symbol would be a good idea, I think, but a better
> > > approach would be:
> > >   - start the environments properly, using a new enum.
> > >   - Separate out those things which need to be "different kinds of
> > >     struct symbol", and keep the factoring at the environment level.
> > >   - Look up environment entries, not struct symbol's.  That way we can
> > >     have a hope of keeping the right names attached to types, for
> > >     instance.
> > 
> > By the last point here, are you suggesting that everyone hand around
> > pointers to `struct environment_entry' objects, rather than pointers
> > to `struct type', `struct field', etc.?  That would lose some
> > typechecking, and some clarity.  If space is the concern, I think I'd
> > rather see both the environment entry and the symbol/field/etc. have
> > `name' fields, that perhaps point to the same string.
> 
> There's a question of correctness, though.  Suppose a type is imported
> into a namespace - we don't want to create a new type for it, but we do
> want to create a new name for it.  I'm not sure what to do.

You mean, imported via `using A::t', or via `using namespace A', where
`A' binds `t' to a type?  I guess I don't see the problem; could you
be more explicit?


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