Re: Boost 1.25.0 build problems?

From: williamkempf_at_[hidden]
Date: 2001-10-10 18:07:28

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > > In fact STLPort is trying to save you from including <string> if
> > you don't
> > > need it.
> >
> > I don't need it.  I didn't use it.  That's the whole point.  The 
fact
> > that the exceptions demand that you use std::string to construct 
them
> > is simply wrong.  Either one or the other cases would be 
acceptable,
> > but what happens here is not.
> >
> > 1)  I don't need <string> to construct an exception with a const
> > char* parameter.
> > 2)  <string> is included by <exception> because I do need it for
> > construction via a const char*.
> >
> > The latter would be acceptable, though it causes extra dependency
> > overhead so the former would be preferred.  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.
> 
> OK, I agree so far.
> 
> > 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.
> 
> This depends on the point of view. On the other side are those that 
include
> <stdexcept> but don't construct exceptions. They really don't need 
<string>
> even by the current rules, so STLPort tries to avoid the dependency.

That doesn't in any way violate my point of view though.  This just 
says that it's better to take option 1 above for these other folks, 
which is why I said the former was preferred.  So this doesn't change 
the fact that it's a QoI issue, only that there's a preferred 
solution for STLPort.  I don't believe that solution would violate 
current standard rules, either.

> Having <stdexcept> include <string> does not help anyone. You can 
simply
> include it yourself without losing anything.

It would have helped me in this case, and wouldn't have "hurt" the 
other camp.  It only adds compile time overhead, which though 
undesirable is not an actual problem.  From my point of view, 
however, needing to include <string> when I don't directly use it is 
a problem.

> > Bottom line is that I don't use std::basic_string anywhere in the
> > code and should not have to include <string> because there's a
> > dependency on it in <exception>.  Either the dependency shouldn't 
be
> > there, or <exception> should include <string> itself.
> 
> Unfortunately you do use std::basic_string, even if you don't spell 
its
> name.

Only because there's a dependency in std::exception, though.  That's 
why I said there should either be no dependency (taken care of by the 
const char* overload solution) or that <exception> should include 
<string>.
 
> In my opinion, it would be much easier to just add const char * 
constructor
> overloads to the standard exception classes than to somehow fix the 
standard
> to allow such code to not be considered 'use' of std::basic_string.

I'd agree with this, and is what I've said over and over in this 
thread ;).

Bill Kempf