|
|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-10 10:03:37
From: <williamkempf_at_[hidden]>
> > In fact STLPort is trying to save you from including <string> if
> you don't
> > need it.
>
> I don't need it. I didn't use it. That's the whole point. The fact
> that the exceptions demand that you use std::string to construct them
> is simply wrong. Either one or the other cases would be acceptable,
> but what happens here is not.
>
> 1) I don't need <string> to construct an exception with a const
> char* parameter.
> 2) <string> is included by <exception> because I do need it for
> construction via a const char*.
>
> The latter would be acceptable, though it causes extra dependency
> overhead so the former would be preferred. This is all a technical
> problem with the current definition in the standard and so STLPort is
> fully conforming and I do have to include <string> myself.
OK, I agree so far.
> However,
> I contend this is also a QoI issue because STLPort didn't have to
> take this route in their implementation even if the standard allows
> it.
This depends on the point of view. On the other side are those that include
<stdexcept> but don't construct exceptions. They really don't need <string>
even by the current rules, so STLPort tries to avoid the dependency.
Having <stdexcept> include <string> does not help anyone. You can simply
include it yourself without losing anything.
> Bottom line is that I don't use std::basic_string anywhere in the
> code and should not have to include <string> because there's a
> dependency on it in <exception>. Either the dependency shouldn't be
> there, or <exception> should include <string> itself.
Unfortunately you do use std::basic_string, even if you don't spell its
name.
In my opinion, it would be much easier to just add const char * constructor
overloads to the standard exception classes than to somehow fix the standard
to allow such code to not be considered 'use' of std::basic_string.
-- 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