C++ nested classes, namespaces, structs, and compound statements

[Jim Blandy]

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?