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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2001-10-06 10:40:01

On Saturday, October 6, 2001, at 10:46  AM, Peter Dimov wrote:

> From: "Howard Hinnant" <hinnant_at_[hidden]>
>>> If you explicitly use a standard defined name, then you must 
>>> explicitly
>>> include the associated header.  Otherwise you do not have to include
>>> the header, even if you are implicitly referring to said object.
>>
>> Of course the above "rule" would have to be encoded in standard-eze so
>> that only high priests are capable of interpreting its true 
>> meaning. ;-)
>>
>> Under this rule, Beman's example would be conforming because it only
>> implicitly refers to std::string, not explicitly.  Thus #include
>> <string> is not necessary.  If the example were changed to:
>>
>>         lock_error() : std::runtime_error(std::string("thread lock
>> error")) { }
>>
>> then #include <string> becomes necessary.
>
> What is the difference between the two examples? You can't add a char 
> const*
> overload without breaking code AFAICS.
>
> struct X
> {
>     operator std::string () const;
>     operator char const* () const;
> };
>
> std::runtime_error(X());

Don't they shoot programmers for doing this? :-)

One difference is that vendors of <stdexcept> have the freedom of using 
compiler magic to make it work.

That being said, the Metrowerks runtime_error is implemented exactly as 
you allude, and has been for several years.  I've yet to receive a 
single complaint on the issue.  But perhaps it is time to revisit it.  
There may be other techniques for achieving the same end.  Or perhaps I 
will resort to compiler magic.

In any event, I still think there is a valuable difference.  Our 
containers (e.g. <vector>) are examples of clients who need to throw 
simple exceptions (from <stdexcept>), but don't want the overhead of 
including <string>.  And if I find that desirable in my own code, it 
makes it very easy for me to imagine that others value this ability as 
well.

-Howard