Quantcast

Rebooting Boost: Call for Lightning Talks @ CppCon

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Rebooting Boost: Call for Lightning Talks @ CppCon

Niall Douglas
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/



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

SMime.p7s (8K) Download Attachment
Loading...