|
Boost : |
Subject: Re: [boost] [log] [asio] Conflicting default configs
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-03-31 04:47:56
On Tuesday 31 March 2015 11:38:45 you wrote:
> On Tuesday 31 March 2015 20:05:42 Gavin Lambert wrote:
> > On 31/03/2015 13:41, Niall Douglas wrote:
> > > On 31 Mar 2015 at 1:54, Andrey Semashev wrote:
> > >> 1. Introduce an inline ABI namespace in Boost.ASIO, much like the one I
> > >> have in Boost.Log. The namespace name would depend on
> > >> BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION and other macros that
> > >> affect
> > >> binary compatibility. This would be my preferred solution, although I'm
> > >> not
> > >> sure how fast and easy it can be implemented.
> > >
> > > Why don't you just use standalone ASIO internally? It has a different
> > > ABI, and I believe is expected to not interact with Boost.ASIO.
> > >
> > > The internal copy can be generated using Chris's special "include all
> > > of ASIO" magic file. Just fire it through a bit of python which
> > > implements only the #include directive or use a STL excluding
> > > preprocessor to generate a single file including all of standalone
> > > ASIO.
> >
> > If you can tweak the namespace it uses to be something inside boost::log
> > rather than whatever it defaults to, that should help avoid collisions
> > between Boost.Log and either Boost.Asio or the user using standalone
> > ASIO themselves.
>
> Hmm, this made me thinking if I could #include Boost.ASIO headers inside a
> namespace. Sounds hackish and certainly not the expected use case by ASIO
> developers, but it could work.
On the second thought, no, this won't work because other headers, including
Boost, STL and system headers, will be included under my namespace and this
will certainly break at some point.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk