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

[Daniel Jacobowitz <drow@mvista.com>]

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