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