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