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

Daniel Jacobowitz
2002-04-12T23:56:02Z

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