From: Howard Hinnant (hinnant_at_[hidden])
Date: 2001-01-08 17:54:12
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.) In fact,
>this specialization may not be allowed, depending on how section 126.96.36.199
>(paragraph 1) is supposed to be interpreted. (Can "T" count as depending
>on an user-defined name [of external linkage]? What if "T" is something
>like "float," would it ruin the idea?)
>1. The technique requires partial specialization, which not all of the
>compilers we talk about support.
>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. (How
>would we justify the syntax to a newbie?) A separate class template shows
>clearer intent and more-justifiable leeway to change the interface.
I think you've misunderstood my intent. I originally posted this thread
to comp.lang.c++ with the statement:
>I'm thinking along the lines of this being part of the next C++
>standard. But it needs lots more field testing and thought than I can
>give it alone.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk