Date: 2001-10-04 14:30:38
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 01:08 PM 10/4/2001, Peter Dimov wrote:
> >From: <williamkempf_at_h...>
> >> > Looks like basic_string is only fwd declared at his point.
> >> I'm not sure if STLPort is compliant here or not, but this
> >> grief. The standard explicitly says that the std::exception
> >> should all take an argument of type "const string&" in their
> >> constructors. The fact that the type is a reference may allow
> >> implementations to only forward declare std::string here, but
> >> so is a questionable practice as it doesn't accomplish much of
> >> anything. Any code that constructs a std::exception type is
> >> have to include <string> any way, so very few compilation units
> >> benefit from the "optimization". It won't hurt for me to
> >> <string> in <boost/thread/exceptions>, but I really question
> >> should have to.
> >Because the standard says so. If you use std::string, you have to
> ><string>. Other headers are not required to do it for you, even
> >interfaces mention std::string.
> That's my reading too. IIRC, it is also one of the examples Andy
> gives of why the current rules can lead to user confusion.
> My reading of the rules is that if a standard library header
> definition of a type (presumably because it needs a complete type),
> appropriate standard library header has to be included by the
> implementation. But if only a declaration is required (because the
> is such an incomplete type is OK), the full header doesn't have to
Well, I suspected that technically it was compliant, but regardless I
view this as a QoI issue. There's such little benefit gained by
forward declaring std::string in this case that it's a pain to
require its inclusion. The current case is a great example of why I
feel this way. None of the Boost.Threads code uses std::string at
all, so I should not be required to include it myself just because I
use std::exception types.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk