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