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

From: Ross Smith (ross.s_at_[hidden])
Date: 2001-05-30 16:19:16

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_[hidden]> The Internet Group, Auckland, New Zealand
========================================================================
        "Hungarian notation is the tactical nuclear weapon of
         source code obfuscation techniques." -- Roedy Green