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

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

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, gregod at, cpdaniel at, john at