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

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Apr 16, 2002 at 02:07:22PM -0500, Jim Blandy wrote:
> 
> 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?

Well, neither of those exactly - in those cases the type is still named
't'.  The only interesting problem with those examples is whether the
type is still named A::t (as opposed to new_namespace::t) in that case;
I'm not sure what C++ says about that.

I was talking about this example from Daniel Berlin:

#include <string>

using namespace bob = std;

bob::string a;

It doesn't seem to be the problem I thought it was, since it only
happens to namespaces and not to namespace members like types.  So this
is not a real problem.

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