|
Boost : |
Subject: Re: [boost] Versioned namespaces (was Rebooting Boost: Call for Lightning Talks @ CppCon)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-05-22 09:01:41
Le 22/05/2016 à 13:18, Niall Douglas a écrit :
>
> Here is an example of such a lightning talk:
>
>
> 1. Current design pattern:
>
> Library v1.00:
> namespace boost { namespace lib { void foo(size_t, char); } }
>
> User code:
> boost::lib::foo(100, 'n');
>
>
> 2. Problem:
>
> Library v1.01:
> namespace boost { namespace lib { void foo(char, size_t); } }
>
> User code:
> boost::lib::foo(100, 'n'); // oh oh!
>
>
> 3. Alternative:
>
> Library v1.00:
> namespace boost { namespace lib { inline namespace v100 { void
> foo(size_t, char); } } }
> #define BOOST_LIB_NAMESPACE_V100 boost::lib::v100
>
> Library v1.01:
> namespace boost { namespace lib { inline namespace v101 { void
> foo(char, size_t); } } }
> #define BOOST_LIB_NAMESPACE_V101 boost::lib::v101
>
> User code:
> // Mount v100 of Boost.Lib into "lib"
> namespace lib=BOOST_LIB_NAMESPACE_V100;
> lib::foo(100, 'n'); // ABI stable! No ODR violation possible!
I believed that minor version should be ABI compatible. I don't see the
need to use namespaces for minor versions. When do you need to version them?
Why do you need macros here? What is wrong with
namespace lib=boost::lib::v100;
?
>
> 4. Problems fixed:
>
> a) Mixing incompatible versions of individual Boost libraries in the
> same process (or even translation unit) is now safe.
As far as all applications are using a specific version.
I don't think this is a good goal. How different versions interact?
Wouldn't this increase the current interoperability problem between
boost and the standard library, but now between several boost versions?
>
> b) Libraries can now depend on other libraries without worrying about
> breaking code which depends on them which uses a different version of
> the same dependency. This greatly helps reduce change ripple effects.
Agreed.
>
> c) Forward compatibility or alternative implementation shims are now
> very easy to implement e.g. library users can externally configure
> either Boost.Filesystem or std::experimental::filesystem for your
> library to use, your code simply refers to _some_ Filesystem TS
> implementation e.g.
>
> namespace filesystem = FILESYSTEM_TS_IMPLEMENTATION;
> filesystem::path mypath;
>
Hmm, if Boost.Filesystem is a conforming implementation of the TS
Filesystem, it should provide a a <filesystem> file included in the
std::experimental::filesystem namespace and then the user wouldn't need
to do anything at the source level, but at the configuration level.
I would add a section of what problem could be introduced ;-)
Should the versions duplicate the whole code? If not, how this
duplication is avoided?
How the user can partially specialize a class? inside the versioned or
not versioned namespace? If we want to allow several version on a
process, it should be the versioned one.
What is the advantage of inlining the version namespaces if the user
cannot use it directly?
Best,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk