Re: [v3] std::tr1::array

[Matt Austern <austern at apple dot com>]

On Oct 11, 2004, at 3:05 PM, Benjamin Kosnik wrote:

> > I deleted members not mentioned in TR1, I'll be doing a thorough 
> > review
> > before I'm finished.  There are still a few places that don't conform 
> > to
> > C++STYLE, and I have a few questions:
> >
> > Should I have put helpers in __gnu_cxx, or in e.g. __gnu_tr1 ?
>
> Wow. That's a good question.  Do you think the helpers are generally
> useful? If so, I'd say __gnu_cxx. If not, I'd say __gnu_tr1.
>
> This kind of thing we can always change as we get more experience with
> this.
>
> > What's the proper policy on uglification? Do *all* non-standard names
> > have to be uglified?
> > e.g. std::tr1::shared_ptr uses a __gnu_cxx::__shared_count,
> > shared_ptr::use_count() calls __shared_count::use_count(),
> > shared_ptr::unique() calls __shared_count::unique(),
> > shared_ptr::release() calls __shared_count::release() etc.
> >
> > Do I need to uglify the __shared_count members, so e.g.
> > shared_ptr::unique() calls __shared_count::_M_unique() ?
> > (I have done so, but can easily undo it)
>
> Man, do the uglification rules ever need to be explained. I find myself
> wondering about this issue a lot as well.

I'm going to toss out an alternative suggestion: let's not uglify the
TR1 components.

First: uglification isn't really a service to the user.  It's a service 
to
strict standard conformance.  We need it to pass conformance test
suites, and not really for any other reason.  Since nothing in TR1 is
normative, and there are no strict conformance test suites for TR1,
this isn't an issue.  This is all an extension anyway.

Second: when and if this stuff goes into the standard, we'll have
had time to use a better mechanism.  Bjarne is working on some
preprocessor extensions that will keep user macros from interfering
with standard headers, and that's a better solution than uglification.
I expect that something like the #scope directive will make it into
C++0x (Bjarne usually gets what he wants), but even if it doesn't
we can implement it as a GCC extension.

				--Matt