From: williamkempf_at_[hidden]
Date: 2001-10-04 17:08:10
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> >
> > There's the rub, though. I never used "a name from the standard
> > library" for which I did not "include a standard library header
> > documented as providing that name". The issue actually stems from
> > calling the constructors with const char* parameters which need
to be
> > implicitly cast to the const std::string& type. So I guess you
could
> > turn this around and claim that the standard has a defect in
design,
> > but I don't care to go that far. I honestly think this is a QoI
> > issue with STLPort.
>
> Arguably. Is it better to break loudly when the user does something
> nonportable, or to understand their intention and "just work"?
It can be argued, though, that I didn't do anything "nonportable".
I've included all the relevant headers according to the requirements
of the standard with one viewpoint on this. Technically I haven't
since I inderectly used std::string by calling the std::exception
type's constructor, but then we come back to wondering if the design
of the std::exception types are broken. I *truly* don't think it's
unreasonable to expect that I shouldn't have to explicitly include
<string> when I construct a std::exception type if I never use
std::string myself. I don't really care if <exception> includes
<string> or not, so long as I don't have to do so myself when I never
use std::string. There's two ways to do this right in my mind:
either <exception> must include <string> or all std::exception types
need to have overloaded constructors that take const char* parameters.
Bill Kempf