Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Sam Kellett (samkellett_at_[hidden])
Date: 2016-02-04 11:05:21

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

> On 4 Feb 2016 at 14:45, Sam Kellett wrote:
>
> > >>> 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
> > >>
> > >>
> > > Eh? That's exactly what happened. Annoying warnings with no other
> issues.
> >
> >
> > sorry i don't think that came off how i meant it... what i mean is this
> is
> > kinda asking for trouble. what happens if the boost macro changes?
> >
> > wouldn't something like this be better:
> >
> > #ifdef BOOST_XXX
> > #define MY_XXX BOOST_XXX
> > #else
> > #define MY_XXX /* boost_lite thing here */
> > #endif
> >
> > redefining a macro in somebody else's 'namespace' is akin to opening up
> the
> > std namespace to redefine vector.
>
> This is exactly what my Boost-lite emulation already does.
>

it can't be exactly what your boost-lite emulation does else you wouldn't
get redefinition warnings. i'm not redefining anybody else's macros...

>
> The problem is when you include my stuff first and then include Boost
> without telling my stuff you actually want to use Boost, then Boost's
> definitions collide with my emulated ones.
>

this problem doesn't exist at all if you stick to defining macros with your
own prefix...

>
> If Boost did as you suggested there would be no warnings, and I'm
> defining the same functionally speaking thing as Boost is so there
> should be no breakage (insert many caveats omitted for brevity here).
>

so boost should assume that at any time somebody else may change or replace
their code? how is that practical / possible to test?

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

> On 4 Feb 2016 at 14:45, Sam Kellett wrote:
>
> > >>> 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
> > >>
> > >>
> > > Eh? That's exactly what happened. Annoying warnings with no other
> issues.
> >
> >
> > sorry i don't think that came off how i meant it... what i mean is this
> is
> > kinda asking for trouble. what happens if the boost macro changes?
> >
> > wouldn't something like this be better:
> >
> > #ifdef BOOST_XXX
> > #define MY_XXX BOOST_XXX
> > #else
> > #define MY_XXX /* boost_lite thing here */
> > #endif
> >
> > redefining a macro in somebody else's 'namespace' is akin to opening up
> the
> > std namespace to redefine vector.
>
> This is exactly what my Boost-lite emulation already does.
>
> The problem is when you include my stuff first and then include Boost
> without telling my stuff you actually want to use Boost, then Boost's
> definitions collide with my emulated ones.
>
> If Boost did as you suggested there would be no warnings, and I'm
> defining the same functionally speaking thing as Boost is so there
> should be no breakage (insert many caveats omitted for brevity here).
>
> Niall
>
> --
> ned Productions Limited Consulting
> http://www.nedproductions.biz/
> http://ie.linkedin.com/in/nialldouglas/
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>