Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-02-04 03:16:15

On 3 Feb 2016 at 17:18, Robert Ramey wrote:

> >> You're using Outcome in standalone non-Boost configuration in
> >> combination with Boost, so the "Boost-lite" emulation it configures
> >> will collide with Boost.
> >>
> >> As you noticed if you include Outcome after Boost it spots you've
> >> already included Boost and turns standalone off.
> >>
> >> You can configure Outcome to use Boost natively from the get go via
> >> macros. See its config.hpp. Or just keep including Outcome after all
> >> other Boost headers.
> 
> I think it's very unwise to make behavior of some library dependent upon 
> header order.  It's fragile and non-intuitive and leads to bugs or 
> unexpected behavior which can be very, very, very hard to find.

Ordinarily yes. In this case however, the Boost-lite macros have the 
same effect as the Boost ones, so redefining them is mostly safe, 
albeit with annoying warnings.

For the record, it is Boost which is at fault here, not my code. 
Boost should not be unilaterally setting BOOST_* macros without 
checking if they are already defined.

> > Ah I see, clever, thanks.
> 
> No doubt - but perhaps too much so.

Maybe for some. However my Boost abstraction layer has proven to be 
an enormous boon for my development productivity - no more messing 
around with config, build or installing dependencies. I just get to 
work knowing the resulting libraries will take advantage of Boost 
where available/needed, and if not fall back on the C++ 14/1z STL 
with Boost-lite emulation. I recently started porting AFIO v2 to 
POSIX, and I was quite surprised the very first time I pressed 
compile it actually "just worked" picking up Boost.Filesystem 
automagically on that platform (the clang now bundled with VS2015 
Update 1 also helped a lot of course to ensure the code written on 
Windows would compile without error on FreeBSD's clang).

I'm very pleased with the layer, anyway, it is worth every day all 
those months I poured into developing it.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/