From: Howard Hinnant (hinnant_at_[hidden])
Date: 2001-10-11 09:10:02
On Thursday, October 11, 2001, at 09:56 AM, Peter Dimov wrote:
>> Do we need to include <memory>? I hope not. But how do we know that
>> don't need to include <memory>? Once we've decided that we don't need
>> to include <memory> in the above example, is this code legal:
>> #include <string>
>> std::allocator<char> a;
>> I hope not. Though I'm guessing it would work on most of today's
>> platforms anyway.
> I wonder how can one prohibit the latter while allowing the former
> adding a default constructor overload to basic_string. After <string>
> std::allocator<char> either can be constructed or it cannot.
Ahh... I think an important distinction should be made here. To say
"not legal" is one thing. To actively prohibit is something else.
Perhaps "not legal" is even too strong. How 'bout "not guaranteed to
I do not suggest that a platform must diagnose this latest example. I
merely suggest that it is not portable. There may be ways of
implementing <string> that take short cuts (perhaps in the name of
efficiency) which do not actually instantiate allocator<char>, but
simply behave /as if/ they do. And no, I don't have such a way in my
back pocket to give as an example right now. I'm merely theorizing that
such a way might exist.
PS: There may be those wondering what this has to do with Boost. I
feel that design of the std::lib is relevant as it can influence the
design of boost libraries (and vice versa). However if anyone feels we
should take this discussion elsewhere, I'm happy to do that.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk