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

Daniel Jacobowitz
2002-04-10T19:08:22Z

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.

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.

> Getting too technical for this point in the discussion: I like doing
> subclassing of structs in C like this:
>
> struct environment_entry {
> const char *name;
> enum name_type kind;
> };
>
> struct field_entry {
> struct environment_entry env;
> enum field_visibility visibility;
> struct type *type;
> ...
> };
>
> Since C guarantees that a pointer to a struct can be safely converted
> to a pointer to its first member and back, this is okay. And while
> going from superclass to subclass still isn't typesafe, going from
> subclass to superclass is. (The down-casting should be hidden in a
> function which also checks the tag.)
>
> But this is just bikeshedding. I like your basic idea, however one
> implements it.

I actually have a significant gripe with this technique. If we're
going to do it, we should use accessor functions (inline or macroized,
please...) in both directions. It's very confusing when you see such
a thing to have to go check the definition - "is that the first member?
Is this reversible?"

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