From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-10-05 09:27:08
At 06:08 PM 10/4/2001, williamkempf_at_[hidden] wrote:
>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.
Maybe you ought to write up a defect report. It will be easier for the LWG
to understand the issue if you boil it down to a very simple piece of code
that you want to know is or isn't conforming.
Let's see. Something like this:
#include <stdexcept>
class lock_error : public std::runtime_error
{
public:
lock_error() : std::runtime_error("thread lock error") { }
};
Is this conforming code? Note the lack of #include <string>,
that std::runtime_error() takes a const string& argument, and
there is no constructor taking a const char*.
Post it on comp.std.c++ with a subject that begins "Defect Report:"
Note that the only way under ISO rules to get an official interpretation is
via the Defect Report mechanism. As a practical matter, people who often
need interpretations join the C++ Committee, and thus get access to the
committee's mailing lists.
--Beman