Re: GCC, stringstreams, and boost/config.hpp

From: deansturtevant_at_[hidden]
Date: 2001-05-31 06:18:26

Here's the simplest solution - people who have compilers without 
sstream should use -DBOOST_NO_SSTREAM on the command line to the 
compiler. No hacks necessary!
- Dean
--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> Jens Maurer wrote:
> > 
> > Beman Dawes wrote:
> > >
> > > At 10:01 PM 5/28/2001, David Abrahams wrote:
> > >
> > >  >How about this?
> > >  >Targets wishing to use sstream simply #include it.
> > >  >We add our own <sstream> to the path /behind/ the system 
#includes, so it
> > >  >will only be found if the implementation fails to conform. We 
#define
> > >  >BOOST_NO_SSTREAM in our <sstream>
> > >
> > > Is there a variation of this approach so only users of systems 
which don't
> > > support <sstream> would have to worry about order of #include 
paths?
> > >
> > > I don't mind making users of non-conforming libraries have to 
do something
> > > special, but don't want users of conforming libraries having to 
worry about
> > > #include search order.
> > 
> > I believe that David's suggestion does exactly this:  People who 
have
> > <sstream> just ignore that there's some workaround deep within 
boost.
> > People# without <sstream> need to fix their #include paths so that
> > boost's workaround <sstream> is found.
> 
> If people don't have <sstream>, they don't need to set up their 
include
> paths the way David suggested because there's no native <sstream> 
to be
> found, so it doesn't matter where Boost's <sstream> goes. So one
> solution would be to put a fake <sstream> somewhere in the Boost 
package
> where it won't normally show up in the include path at all, and tell
> people with no native <sstream> to move that file to somewhere on 
their
> include path.
> 
> -- 
> Ross Smith <ross.s_at_i...> The Internet Group, Auckland, New Zealand
> 
======================================================================
==
>         "Hungarian notation is the tactical nuclear weapon of
>          source code obfuscation techniques." -- Roedy Green