Re: [boost] Re: Boost 1.25.0 build problems?

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