On May 22, 2016 9:01:41 AM EDT, "Vicente J. Botet Escriba"
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!
In my opinion, this is the wrong question you should be asking. I don't know your organizational constraints or how you enforce version of third party libraries, but that very activity is the better question you should be asking. HTH
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?
I didn't know what the heck y'all were talking about with so-called "ABI compatibility", but now I do, or at least I have a better idea. But now I do; it just sounds to me more like a non-solution that cops out of a non-problem. In my opinion, this should never be the question. What ever happened to maintaining backwards compatibility, managing breaking changes, etc. Even at the risk of offending someone.
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-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.