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

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Apr 12, 2002 at 03:58:21PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Wed, Apr 10, 2002 at 12:31:27PM -0500, Jim Blandy wrote:
> > > Daniel Jacobowitz <drow@mvista.com> writes:
> > > > Sure.  But I think this is a chance (if we want one) to move in a
> > > > different direction.  We'd have to work out the details, but I envision
> > > > something like this (names made up as I go along):
> > > > 
> > > > struct environment_entry {
> > > >   const char *name;
> > > >   enum name_type kind;
> > > >   void *data;
> > > > }
> > > > 
> > > > enum name_type {
> > > >   type_kind,
> > > >   field_kind,
> > > >   symbol_kind,
> > > >   namespace_kind,
> > > > };
> > > 
> > > In other words, replace the sloppy union with a properly discriminated
> > > union?  I'm for it.
> > > 
> > > But granted that it's important to clearly distinguish between the
> > > expanding set of uses we're putting `struct symbol' to, and that
> > > extending enum address_class isn't the best idea, how is it better to
> > > make this change concurrently with the enclosing environment changes?
> > > We could do this change right now.  Isn't it basically independent?
> > 
> > Well, no.  I was suggesting this for things that are not currently in
> > symbols (well, types generally are...).  But namespaces are not
> > represented at all and fields are in a different structure entirely.
> 
> Okay, I think I see.  You're preserving the distinctions implicit in
> the existing structures (fields and symbols are separate),
> distinguishing types from symbols (i.e. an entry for a typedef would
> be an environment_entry whose kind == type_kind, instead of a symbol
> with an address class of LOC_TYPEDEF), and positing that namespaces
> would be a fourth kind of thing.  The `data' field would point to a
> `struct type' or a `struct field', or whatever.

Yes, that's right.  There's also transparent scopes (which might be a
special kind of namespace... or not).  By that I mean {} enclosed
regions with their own local variables.  A function belongs to a
namespace, a namespace does not enclose a particular range of PCs - but
a scope does enclose a particular PC range.  Hopefully but not
necessarily a single contiguous range.  Optimization or explicit
.section directives could break it up.

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

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