From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-11 08:56:22
From: "Howard Hinnant" <hinnant_at_[hidden]>
> On Thursday, October 11, 2001, at 07:13 AM, Peter Dimov wrote:
> > Let's go back to the original question: is std::ostringstream a complete
> > type after <sstream> has been included?
> I'm not sure (and I would like to be).
> I've read 27.7 and the only thing I can say for sure is that after
> including <sstream> std::ostringstream is a typedef for
> std::basic_ostringstream<char>. And std::basic_ostringstream<charT +
> defaults> is a class _template_.
> So perhaps the question can be reworded: Is a class template a complete
The answer is clearly 'no' - a class template is not a type, so it can't be
a complete type. But a class template instantiation - like
std::basic_ostringstream<char> - is a type, and I believe that it must be
complete after <sstream>, because there is no other mechanism - besides
#include <sstream> - available that ensures completeness.
> Before we get too far down the inheritance argument, there are other
> examples which don't include inheritance. Is this portable code?
> #include <string>
> std::string s;
> I hope yes. But we've just instantiated and constructed a
> std::allocator<char> (at least conceptually) which is defined over in
> template<class charT, class traits = char_traits<charT>,
> class Allocator = allocator<charT> >
> class basic_string
> explicit basic_string(const Allocator& a = Allocator());
This example, on the other hand, represents a real problem. It's very
similar to the <stdexcept> + <string> case; the std::string construction
implicitly constructs an Allocator temporary.
> 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>
> 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.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk