Re: [boost] Re: Boost 1.25.0 build problems?

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 
>> we
>> 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>
>>
>> int
>> main()
>> {
>> 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 
> without
> 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 
work"?

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.

-Howard