Rebooting Boost: Call for Lightning Talks @ CppCon
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*". Recent and recurrent boost-dev discussions have raised the lack of cmake based tooling; lack of ABI management and the consequent ODR violation when mixing Boost versions in the same process; the anti-social behaviour of Boost towards library end users, new ideas, new blood and the wider C++ community; and the chronic lack of maintenance of up to half the Boost libraries. One question which needs to be answered is whether a clean reboot of Boost from the first principles of proving high quality C++ libraries well suited for use with the latest C++ standard is viable. This new collection of C++ libraries would be started completely from scratch (even if some existing libraries were ported into the new organisation), so ANYTHING is possible. All we need is a critical mass of library developers willing to collaborate on developing a shared infrastructure mutually beneficial to all participants, whether library developer or library end user. To that end of discovering if this critical mass is there, five minute lightning talk topics are requested for CppCon this September on this topic: "What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" Please keep each talk topic focused on a single design pattern, practice or idiom (see suggested talk format below). Each speaker may submit up to THREE talk topics (not all may be accepted if there are a lack of slots, so please rank them in order of preference). Please send your talk topics to me privately by email, only if sufficient numbers present to fill a session will your name and your talk topic be shared with the CppCon Programme Committee. We'll try to arrange a short panel session at the end so attendees can ask questions of the speakers. After the lightning talk we'll arrange a restaurant so all the speakers and any interested attendees can dine together, followed by a night in a Bellevue bar. If after the dust has settled it is felt there is a critical mass sufficient to reboot a brand shiny new edition of Boost, we'll start development! I should *stress* that it is up to the CppCon Programme Committee whether these lightning talks are approved or not. I'll just copy and paste your proposed talk to the CppCon PC as-is. If insufficient lightning talk topics are received by me to fill a 60 minute session, I'll withdraw this talk proposal from CppCon. Suggested talk format ================ Five minutes is not much time, so here is a suggested lightning talk outline: 1. A current widely practiced library design pattern (show example). 2. The problems it generates for library users or maintainers. 3. Your proposed alternative design pattern (show example). 4. The problems the alternative design pattern fixes. 5. Any mockup, prototype or even live demo (!) of the alternative design pattern in action. Suggested talk themes might be documentation, packaging, distribution, testing, tooling, quality assessment, barriers to entry, governance, strategy, important gaps in the standard libraries, automation and deprecation/removal policies. 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! 4. Problems fixed: a) Mixing incompatible versions of individual Boost libraries in the same process (or even translation unit) is now safe. 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. 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; -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 22/05/2016 à 13:18, Niall Douglas a écrit :
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*". I agree completely. Recent and recurrent boost-dev discussions have raised the lack of cmake based tooling; I agree also that we should provide a way to build Boost with CMake. lack of ABI management Agreed, but I don't know how to check this. and the consequent ODR violation when mixing Boost versions in the same process; I'm not sure this should be something we want to provide. Does the standard libraries have this goal? the anti-social behaviour of Boost towards library end users, Could you elaborate? new ideas, new blood and the wider C++ community; and the chronic lack of maintenance of up to half the Boost libraries.
One question which needs to be answered is whether a clean reboot of Boost from the first principles of proving high quality C++ libraries well suited for use with the latest C++ standard is viable. This new collection of C++ libraries would be started completely from scratch (even if some existing libraries were ported into the new organisation), so ANYTHING is possible. All we need is a critical mass of library developers willing to collaborate on developing a shared infrastructure mutually beneficial to all participants, whether library developer or library end user. Count with me, at least for defining the goals ;-)
To that end of discovering if this critical mass is there, five minute lightning talk topics are requested for CppCon this September on this topic: I'm almost sure I couldn't be there this year :( "What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" I don't see how this is related to Rebooting Boost. Could you elaborate? Should the talks address whatever issue concerns Boost and how Rebooting Boost would solve them?
Best, Vicente
On 22 May 2016 at 09:37, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
I agree also that we should provide a way to build Boost with CMake.
There is guy named Ruslan Baratov that runs a kick-ass-CMake-based package manager called hunter that integrates the build of Boost with CMake. If you have not checked it out, then it is well worth paying a visit to the Boost page on the wiki: https://github.com/ruslo/hunter/wiki/pkg.boost It is not a pure CMake build, but it is well integrated to the point that you won't really need one unless you have very specific needs. It takes the CMake toolchain configuration into account to build it, as an example of the integration it provides. The project's github page is: https://github.com/ruslo/hunter . Check it out -- Alexandre Pretyman
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
On May 22, 2016 9:01:41 AM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
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.
On Sun, May 22, 2016 at 6:18 AM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*".
You should always strive to provide proper citations when quoting people. It usually provides needed context to discussions. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 05/22/2016 07:18 AM, Niall Douglas wrote:
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*".
... <snip> ... I have been a (minor, but long running) contributor to Boost for quite a while, and while I don't have the time to comment individually on all the various discussions happening on different ways to evolve Boost, I do want to make one general comment. I agree that Boost should serve the entire C++ community. In fact, I would like to see all capable members of the C++ community find ways to serve the community. However, my experience in the last nearly 20 years of service to that community is that almost no two people agree on what is and is not a service to the community. I have, in that time, found no value in arguing with people that my idea of service is better than theirs. As such, I root for all attempts at service to succeed. To find at least some segment of the community for which that service honestly improves the language and the quality of code being produced in the language. So, if you want to serve by trying something new and different - I wish you well. If you want to serve by doing something tried and true, I again have nothing but respect for your desire to serve, and hope for you to succeed. If you want to try to work within existing projects to try and tweek them toward some direction you find more likely to succeed, once again you have my support for your desire to make a difference. I will make my own choices of what to lead or follow, based on my own (admitedly limited) understanding of the needs of the community, and of my own skills and interests. I expect all others to do the same. I will only object if I feel people are somehow being forced to work against their desires and understanding. I see no reason for strained tempers and acrimony in any part of this. John Phillips Boost Review Wizard PS - Though I have held a position in Boost for many years, this statement should be seen only as my own. No "official" representation of any part of Boost, or of Ron Garcia (the other Review Wizard) should be read into this statement. I signed with my position only to make it clear that I have put some time and personal stake into Boost, and I am not talking from no experience of the community.
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Phillips Sent: 23 May 2016 04:06 To: boost-users@lists.boost.org Cc: boost@lists.boost.org Subject: Re: [Boost-users] Rebooting Boost: Call for Lightning Talks @ CppCon
On 05/22/2016 07:18 AM, Niall Douglas wrote:
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*".
... <snip> ...
I have been a (minor, but long running) contributor to Boost for quite a while, and while I don't have the time to comment individually on all the various discussions happening on different ways to evolve Boost, I do want to make one general comment.
I agree that Boost should serve the entire C++ community. In fact, I would like to see all capable members of the C++ community find ways to serve the community. However, my experience in the last nearly 20 years of service to that community is that almost no two people agree on what is and is not a service to the community. I have, in that time, found no value in arguing with people that my idea of service is better than theirs.
As such, I root for all attempts at service to succeed. To find at least some segment of the community for which that service honestly improves the language and the quality of code being produced in the language.
So, if you want to serve by trying something new and different - I wish you well. If you want to serve by doing something tried and true, I again have nothing but respect for your desire to serve, and hope for you to succeed. If you want to try to work within existing projects to try and tweek them toward some direction you find more likely to succeed, once again you have my support for your desire to make a difference.
I will make my own choices of what to lead or follow, based on my own (admitedly limited) understanding of the needs of the community, and of my own skills and interests. I expect all others to do the same. I will only object if I feel people are somehow being forced to work against their desires and understanding.
I see no reason for strained tempers and acrimony in any part of this.
Agreed. Paul PS I agree with the original and current strategy of Gradual Evolution, and do not believe that a Big Bang C++XX only is a better idea. If anything, a much better language without the disastrous baggage of C, would be a much better Bold Adventure for those who feel an urge for the new. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
participants (1)
-
Alexandre Pretyman -
John Phillips -
Michael -
Niall Douglas -
Paul A. Bristow -
Rene Rivera -
Vicente J. Botet Escriba