Re: Suggestion: auto_ary

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

--- In boost_at_[hidden], Daryle Walker <darylew_at_m...> wrote:
> on 1/8/01 11:15 PM, William Kempf at sirwillard_at_m... wrote:
> 
> > --- 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.
> [SNIP]
> 
> I'm looking at section 17.4.3.1, paragraph 1.  It says that 
undefined
> behavior results if a specialization doesn't meet the standard 
library
> requirements of the original template.  It doesn't have to be an 
exact match
> (just no noticeable mismatches), but this specialization is doing 
notable
> changes.  Are the changes severe enough to cause a problem?

We're not talking about the same things here.  17.4.3.1 deals with 
specializations of standard library templates, not templates in 
general.  The concepts I'm discussing are either changes to user 
defined types (the Boost smart pointers) or an extension to the 
standard (i.e. a later standard will require this specialization of 
std::auto_ptr).  Neither case fits 17.4.3.1.  To make the 
specialization for std::auto_ptr with the current standard would, 
however, violate this section and so would be non-portable (though 
you could expect it to work on all known compilers despite the 
undefined behavior).  Howard pointed this out, though I'm not sure 
that he was specifically thinking about this section.

Bill Kempf