Re: Suggestion: auto_ary

From: William Kempf (sirwillard_at_[hidden])
Date: 2001-01-08 18:15:09

--- In boost_at_[hidden], Howard Hinnant <hinnant_at_t...> wrote:
> Daryle Walker wrote on 1/8/2001 5:34 PM
> >Remember that std::auto_ptr is a
> >standard class; it's improper for us to make a noticeably different
> >specialization.  (The standard does it to itself with the 
specialization for
> >std::allocator<void>, but it can break its own rules, we can't.)

The standard has rules about specializations needing to follow the 
exact same interface?  I can't find that, and it wouldn't make sense 
for it to.  In general I'd agree that that's a good design rule to 
follow, but with every rule there are exceptions.  I'm not sure that 
this one is an exception, so don't think I'm blindly advocating 
this... I just thought it had enough merit to warrant discussion and 
possibly experimentation.

> >Other difficulties:
> >
> >1.  The technique requires partial specialization, which not all 
of the
> >compilers we talk about support.

Not a valid reason to oppose this for the standard.  Not even a valid 
reason to oppose it for Boost.  In this case it should be easy to 
simulate for compilers that don't support partial specialization 
(note that I've not tried, and VC has bit me enough times that I 
wouldn't bet money on this one).

> >2.  The technique uses an obscure set of types to act as a subtle 
switch of
> >semantics.  Besides the risk of compiler writers forgetting to 
handle
> >partial specialization of this edge case, it seems kind-of hackish.

To be compliant compilers must handle this type of partial 
specialization, and I don't see it as an edge case (the 
specialization, not the specific use to which we've put it).

>  (How
> >would we justify the syntax to a newbie?)

We've already pointed out that the self documenting features of this 
are the appeal.  This comment takes the opposite stance.  Neither is 
substantiated yet, and with out putting it to practice it probably 
can't be.  So we'll have to chalk this up to differing opinions, 
which is what I expected when I posted Howard's original c.l.c++ 
posting.

> I'm happy to discuss it here on boost as well (as William suggested 
by 
> forwarding my post).  But I'm still thinking of this as a proposed 
> addition to the standard.  I'm not concerned about the rules that 
> disallow clients from adding stuff to namespace std.  Nor am I 
concerned 
> about non-compliant compilers.  I realize that this only partially 
fits 
> into the boost "topic".  And if boosters think this is not 
appropriate 
> for boost, I fully understand.
> 
> However I think William's motivation for bringing this to boost was 
to 
> see if people thought that the technique might have value to 
boost's 
> existing smart pointers.  And that aspect seems fully on topic.

Partially.  By bringing it to the Boost smart pointers (which is 
still very debatable on whether or not it should be done) we gain 
expereince with the technique and establish existing practice which 
helps in later bringing it to the C++ standard as a change to 
auto_ptr.  The concept is very intriguing to me, but I'm not sure 
that the benefits outweigh the costs, which boils down to the 
argument about whether to use this or auto_array (or a generitive 
smart pointer).  The only real way to know if the benefits outweigh 
the costs is to put into practice.

Bill Kempf