[c++now] Perhaps of interest to Boost library users
https://plus.google.com/+nialldouglas/posts/DsAdUV4RgY5 Content of post for convenience: Just finished my C++ Now 2015 presentation with exactly one week to go! Currently 90 slides for a 90 minute long presentation, I had originally been worried I'd be boring but I think, even if I do say so myself, that this will be one of the more interesting talks at C++ Now this year. It reviews *ten* C++ 11/14 only libraries close to entering Boost, three of which in detail (Boost.AFIO, Boost.Fiber, Boost.DI) and one in very great detail (Boost.APIBind), indeed I spend about 45 slides on APIBind as I believe it provides the foundation stone for a fully modular C++ 11 only Boost 2.0 branch with very significant improvements over Boost 1.0. I also draw some sweeping personal general opinions from the ten library review, and I'll try to answer these questions: * Why do these libraries require C++ 11 or 14? From an end user perspective. * Is there a common theme of the most popular C++ 11/14 features used? * Is there a common theme in choice of library design and use of third party libraries? * Are there techniques used in one library which would make a lot of sense to be used in another library, but for some reason are not? * Do these new libraries take notice of one another and integrate themselves well with other libraries, or are they ivory towers? * How many of these forthcoming libraries explicitly seek to contribute to future C++ standardization? Boost only a few years ago was in a state of sickly malaise after the exit of several big names who had dominated it since its inception. Indeed, in 2013 no new libraries had entered in two years, and nobody could say if Boost was going to be the venue for the next generation of C++ 11/14 libraries approaching standardisation or whether some other venue (especially WG21 itself) would take over. Since 2013 *seventeen* new libraries have either entered Boost or entered the formal review queue, almost a third of which are C++ 11/14 mandatory libraries, whilst WG21's efforts to invent new libraries have not panned out well to date. Traffic on the Boost mailing lists which had become anaemic has once again returned to mass-delete-without-reading levels. It looks like Boost is going to remain the place to be for the highest quality C++ libraries, especially those intended for eventual standardisation. The big question is whether the C++ 11/14 mandatory libraries are so different from the 98/03 libraries in design and philosophy that a C++ 11/14 only Boost 2.0 distribution is warranted? Robert Ramey will be presenting on his vision for Boost 2.0 at C++ Now 2015, and he kindly has allowed me to add my ha'pennies worth after he finishes during which I will summarise my empirical findings from the ten library review. So watch out for the recorded videos! -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On May 2, 2015 11:41:33 PM EDT, Niall Douglas
https://plus.google.com/+nialldouglas/posts/DsAdUV4RgY5
Content of post for convenience:
Just finished my C++ Now 2015 presentation with exactly one week to go! Currently 90 slides for a 90 minute long presentation, I had originally been worried I'd be boring but I think, even if I do say so myself, that this will be one of the more interesting talks at C++ Now this year. It reviews *ten* C++ 11/14 only libraries close to entering Boost, three of which in detail (Boost.AFIO, Boost.Fiber, Boost.DI) and one in very great detail (Boost.APIBind), indeed I spend about 45 slides on APIBind as I believe it provides the foundation stone for a fully modular C++ 11 only Boost 2.0 branch with very significant improvements over Boost 1.0. I also draw some sweeping personal general opinions from the ten library review, and I'll try to answer these questions:
* Why do these libraries require C++ 11 or 14? From an end user perspective.
* Is there a common theme of the most popular C++ 11/14 features used?
* Is there a common theme in choice of library design and use of third party libraries?
I am a big proponent of discovering themes or patterns. Patterning after someone or something is the highest form of compliment I believe.
* Are there techniques used in one library which would make a lot of sense to be used in another library, but for some reason are not?
Might be difficult to persuade some folks, especially in a thought driven industry such as ours, but when you have, you've got an ally for the foreseeable future.
* Do these new libraries take notice of one another and integrate themselves well with other libraries, or are they ivory towers?
Not sure what you mean by 'integration' here. Indeed, I am a believer in loose coupling, inasmuch as I am that a 'library' or 'module' ought to add something of value, or at least present its differentiating factors. That is, whether it is a clone of something else, necessarily adds something innovative, or is at least thought provoking, etc. That's my half cent, anyhow. Recent libraries and/or candidates that I can think of include, Asio, Context, Fiber, which, to my recollection, have seen discussion very much along these lines. Also, Filesystem is one of the strongest APIs around that I've worked with.
* How many of these forthcoming libraries explicitly seek to contribute to future C++ standardization?
Boost only a few years ago was in a state of sickly malaise after the exit of several big names who had dominated it since its inception. Indeed, in 2013 no new libraries had entered in two years, and nobody could say if Boost was going to be the venue for the next generation of C++ 11/14 libraries approaching standardisation or whether some other venue (especially WG21 itself) would take over.
Speaking as an end user, and as an architect and budding entrepreneur, at any rate, I can tell you it is always a tough choice to consider which dependencies one wants to be taking on which project(s), depending sometimes on the health and overall barometer of the contribution, community, and so on.
Since 2013 *seventeen* new libraries have either entered Boost or entered the formal review queue, almost a third of which are C++ 11/14 mandatory libraries, whilst WG21's efforts to invent new libraries have not panned out well to date. Traffic on the Boost mailing lists which had become anaemic has once again returned to mass-delete-without-reading levels. It looks like Boost is going to remain the place to be for the highest quality C++ libraries, especially those intended for eventual standardisation.
The big question is whether the C++ 11/14 mandatory libraries are so different from the 98/03 libraries in design and philosophy that a C++ 11/14 only Boost 2.0 distribution is warranted? Robert Ramey will be presenting on his vision for Boost 2.0 at C++ Now 2015, and he kindly has allowed me to add my ha'pennies worth after he finishes during which I will summarise my empirical findings from the ten library review. So watch out for the recorded videos!
In my opinion areas such as concurrency, functional, lambdas, etc, have seriously changed the game significantly. For instance, without getting too lengthy, if I need to inject some solution specific code into an event handler, lambdas alone are an interesting option to consider. Sure you could use a standalone function and bind to it, but the very nature of lambdas is compelling when it may not be worth cluttering a namesace with additional symbols. Of course, remaining sufficiently open minded that you don't suffer from hammer/nail syndrome leaves ample room for personal and professional growth, as well as being aware what generations if code have what tools and solutions available to it. Definitely, interesting times to be a C++ guy these days. Good luck, and I look forward to staying tuned! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 3 May 2015 at 6:54, Michael wrote:
In my opinion areas such as concurrency, functional, lambdas, etc, have seriously changed the game significantly. For instance, without getting too lengthy, if I need to inject some solution specific code into an event handler, lambdas alone are an interesting option to consider. Sure you could use a standalone function and bind to it, but the very nature of lambdas is compelling when it may not be worth cluttering a namesace with additional symbols. Of course, remaining sufficiently open minded that you don't suffer from hammer/nail syndrome leaves ample room for personal and professional growth, as well as being aware what generations if code have what tools and solutions available to it.
Interestingly, though perhaps unsurprisingly, in the libraries I reviewed their external user facing APIs are generally identical to what you'd supply in a C++ 03 library. Only internal implementation uses C++ 11/14. I say unsurprisingly because external APIs are always going to be the most conservative design by anyone with experience, however C++ 11 makes possible a "composure through merged namespace" design idiom and C++ 14 makes possible a "composure through lambda" design idiom for external user facing library APIs. Both have major strengths for some use cases over 03 API designs, but right now libraries are only using those designs internally, not in a user facing API.
Definitely, interesting times to be a C++ guy these days. Good luck, and I look forward to staying tuned!
C++ is also beginning to see the next evolution of competition. As much as C++ 11 borrowed enough from D to render it impotent, I suspect C++ is going to have to borrow much more from the new generation of systems programming languages (Rust, Swift, Go) in order to stay relevant. Bjarne's presentation to WG21 this week notwithstanding of course :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (2)
-
Michael -
Niall Douglas