From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2001-10-10 15:07:47
--- In boost_at_y..., williamkempf_at_h... wrote:
> I don't need it. I didn't use it.
The signature of the constructor requires a string, hence you are
using it and you need it according to the current standard. The
fact that there is a conversion from const char* doesn't change
the fact that you are using a string.
> That's the whole point. The fact that the exceptions demand
> that you use std::string to construct them is simply wrong.
This is a defensible complaint about the standard, but it does not
have any bearing on the question whether your code is portable
to all conforming implementations. As things are you must include
<string> to be portable.
> 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.
> 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.
As pointed out by somebody else, this is not a black and white issue.
The route taken by STLport has the advantage that user code that does
not construct a standard exception, and merely catches it, avoids a
dependency on <string>. Therefore, your suggestion would have
disadvantages as well as advantages. The only way to get your desired
advantage without the disadvantage is for the standard to require an
explicit const char* constructor.
> Bottom line is that I don't use std::basic_string anywhere in the
This argument is hard to defend. string may not appear literally in
your code, but in the absence of a const char* ctor your code is
clearly constructing a string.
> and should not have to include <string> because there's a
> dependency on it in <exception>.
There isn't such a dependency in <exception>. There is only a
dependency on a string&. Your code has the dependency on <string>.
Code that doesn't construct an exception does not currently
depend on <string>.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk