RTTI data member names

[Jim Dehnert]

Hi, all,

I've updated all of the status pages _except_ the exception handling
material (that's next), based on the last meeting.  Take a look.
Note that the meeting next week has been cancelled, and the next one
will be on 28 September.

The following issue is one we didn't resolve in the meeting, and the
discussion appears to have died down (can't have that, can we?) without
an apparent concensus.  I find myself leaning towards Martin's
suggestion that the RTTI members be given natural, normative names,
due to his analysis of the downside below and the later observations
that people typically use upper case for preprocessor macro names, and
that most non-standard implementation-provided libraries do the same
without ill effect.  It is clearly legal, and I doubt that it would
cause problems in practice.  But my bias is very mild, and I'd rather
not decide it.  Mark, has your opinion shifted during the discussion?
Does anyone else oppose the suggestion who's just letting Mark present
the case?

Jim

> From loewis at informatik.hu-berlin.de Thu Aug 31 01:38:04 2000
> 
> > Does anyone else have a comment on this issue?  Who suggested making
> > RTTI names non-normative?  Why?
> 
> I think the way it is now, the names are quite clumsy to use, due to
> the underscore business. So I propose two alternatives:
> 
> 1. make them non-normative. That leaves implementations the choice to
>    expose them under more convenient names, or not to expose them.
> 
> 2. Review the decision to make use of reserved namespace.
> 
> I'd like to argue in favour of option 2. Reserved names are necessary
> to avoid conflicts for strict conformance in the following situations:
> 
> 1. During linking, there may be conflicts with other symbols
> 2. On the source level, there may be conflicts with other names in the
>    same scope.
> 3. There may be conflicts with preprocessor symbols.
> 
> Item 1 and item 2 are a non-issue. The names are already in the ABI
> namespace, which has a reserved name in itself. So all names inside
> that namespace automatically get a reserverd mangled name, and cannot
> interfere with other names.
> 
> Item 3 is not a problem, because these names are available only
> through cxxabi.h. Programs using that header are not strictly
> conforming, and must play by the rules imposed by that header, namely,
> not use these names as preprocessor symbols.
> 
> In short, my proposal is to remove the __ in all places, then make the
> fields public.

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272