Boost logo

Boost :

Subject: Re: [boost] expected/result/etc
From: Sam Kellett (samkellett_at_[hidden])
Date: 2016-02-04 08:06:59


On 4 February 2016 at 08:16, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> 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.
>

that's obviously not true seeing as somebody hit this problem seemingly
almost immediately

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.
>

perhaps non-boost libraries shouldn't be using the boost:: and BOOST_
namespaces?

this may be OT but i find it strange that so many potential libraries are
allowed to brand themselves as boost with just a single "this is not an
official boost library" in their readme.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk