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

Jim Blandy
2002-04-12T20:58:25Z

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.

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