List of C++ 11 only Boost libraries and their status?
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list: * Boost.Spirit X3 ETA to Boost review: unknown, last commit was June 2014. * Boost.Proto 0x ETA to Boost review: unknown, last commit was Oct 2013. * Boost.Hana ETA to Boost review: Summer 2015, last commit was today. * Boost.AFIO ETA to Boost review: Already in review queue, last commit was two days ago. * Boost.BindLib ETA to Boost review: Q1 2015, last commit was two days ago. * Boost.Spinlock ETA to Boost review: Q2 2015, last commit was four days ago. * Boost.KernelAlloc ETA to Boost review: Q1 2015, last commit was today. * Boost.Expected ETA to Boost review: no later than Summer 2015 probably much earlier, last commit was two weeks ago. * Boost.CRUX ETA to Boost review: hopefully by end of 2015, last commit was three days ago. I have to admit surprise at how long the list I have collected already is. Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong?
boost.context contains (at least in branch develop) class execution_context (which is C++11 only) - not sure if this is of interest for you. at least execution_context will be the building block for boost.coroutine (makes implementation much easier -> see example section from boost.context).
On 24 Nov 2014 at 13:41, Oliver Kowalke wrote:
Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong?
boost.context contains (at least in branch develop) class execution_context (which is C++11 only) - not sure if this is of interest for you. at least execution_context will be the building block for boost.coroutine (makes implementation much easier -> see example section from boost.context).
Very interesting, and I had no idea. Thanks Oliver. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 24 Nov 2014 at 13:46, Andrzej Krzemienski wrote:
* Boost.CRUX ETA to Boost review: hopefully by end of 2015, last commit was three days ago.
Boost.CRUX? Do you have any link to the library?
https://github.com/maidsafe/MaidSafe-CRUX. This is reliable UDP messaging extension to ASIO we asked for stakeholder feedback on a few weeks ago. I should *stress* that this library is currently in very early stages and very little - apart from what it won't be - is finalised. It may, or it may not, also be dependent on a number of the other libraries I listed earlier. It's a long way out yet, but there is no reason it won't get there by the ETA I specified. It has some very experienced Boost engineers behind it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 24/11/14 12:10, Niall Douglas wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference.
Boost.SIMD, and Boost.Dispatch that it depends on, are now C++11 only. Those libraries have not yet been added to the review queue. The problem with them was compilation speed, a problem that we found easier to solve by moving everything to C++11.
Hi, Not sure if that is interesting for you, but Boost.DI (dependency injection) has C++11 mode (depends on __cplusplus flag). C++14 only version is work in progress - https://github.com/krzysztof-jusiak/di/tree/cpp14. Library hasn't been added to the review queue yet. Cheers, Kris On Mon, Nov 24, 2014 at 1:08 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 24/11/14 12:10, Niall Douglas wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference.
Boost.SIMD, and Boost.Dispatch that it depends on, are now C++11 only. Those libraries have not yet been added to the review queue.
The problem with them was compilation speed, a problem that we found easier to solve by moving everything to C++11.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 24 Nov 2014 at 14:03, Krzysztof Jusiak wrote:
Not sure if that is interesting for you, but Boost.DI (dependency injection) has C++11 mode (depends on __cplusplus flag). C++14 only version is work in progress - https://github.com/krzysztof-jusiak/di/tree/cpp14. Library hasn't been added to the review queue yet.
No it is interesting. Remind me what it does again would you (a quick glance at the Readme did not help)? Was it that new way of doing unit testing thing discussed here some time ago? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Remind me what it does again would you (a quick glance at the Readme did not help)?
Boost.DI it's a dependency injection (http://en.wikipedia.org/wiki/Dependency_injection) library improving manual dependency injection by simplifying object instantiation with automatic dependencies injection. It's a bit like Google Guice for Java (https://github.com/google/guice) or Ninject for C# (http://www.ninject.org). The simplest example di is good at: struct iwriter { ~iwriter() = default; virtual void write() = 0; }; struct writer_impl : iwriter { void write() override {} }; class hello_world { public: hello_world(unique_ptr<iwriter> writer) : writer(writer) { } // construct with iwriter dependency void run() { writer.write(); } private: unique_ptr<iwriter> writer; }; int main() { // automatic dependency using boost.di auto injector = di::make_injector( di::bind<iwriter, writer_impl> // bind interface to implementation ); injector.create<hello_world>().run(); // construct hello world and run it // manual dependency injection auto writer = make_unique<writer_impl>(); hello_world{writer}.run(); // construct hello world and run it } Obliviously automatic di has a lot of pros which can't be seen in above example, you can read a bit more in: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html/di/introduction....
Was it that new way of doing unit testing thing discussed here some time ago? Well, not sure what was discussed, but automatic di let you implement automatic mocks injection, which is really cool and basically let you get rid of writing mocks and creating them for tests (https://github.com/krzysztof-jusiak/mocks_injector)
Hope that helps a bit. Cheers, Kris -- View this message in context: http://boost.2283326.n4.nabble.com/List-of-C-11-only-Boost-libraries-and-the... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 24 Nov 2014 at 14:11, Kris wrote:
Remind me what it does again would you (a quick glance at the Readme did not help)?
Boost.DI it's a dependency injection (http://en.wikipedia.org/wiki/Dependency_injection) library improving manual dependency injection by simplifying object instantiation with automatic dependencies injection. It's a bit like Google Guice for Java (https://github.com/google/guice) or Ninject for C# (http://www.ninject.org).
This library is a very good example of what I am very poor at. I simply don't grok it one bit. This isn't your fault - I don't grok the utility of Google Guice either, or any of the discussion surrounding the pattern on stackoverflow. I suspect this may be due to my "C++ compiler is a fancy assembler macro engine" mentality. I cannot see the wood from the trees here at all. Nevertheless, I would like to attend some sort of tutorial on this library. Are you intending to present at a conference soon? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
*snipped list* Technically, all libraries in Boost are C++11. What's your point? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On Mon, Nov 24, 2014 at 8:20 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
*snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less? Tony
On 24 Nov 2014, at 18:28, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On Mon, Nov 24, 2014 at 8:20 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
*snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less
I think it *is* worth asking "what's the point". For end users whether a particular library uses c++11 features is more-or-less irrelevant - they have a set of real world compilers to support (or justify upgrade from) and so they would love clear statements about what compilers a particular library works on. Of course it is not trivial for an author to supply such a statement - bits of the library may require more modern c++ than other parts - or the minimum feature set required may be inherited from a library used internally by the implementation and this might also change from release to release... I believe Stephen Kelly has posted on this list a couple of times about how CMake tries to address these issues.
On 24 Nov 2014, at 20:03, Pete bartlett <pete@pcbartlett.com> wrote:
On 24 Nov 2014, at 18:28, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On Mon, Nov 24, 2014 at 8:20 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
*snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less
I think it *is* worth asking "what's the point". For end users whether a particular library uses c++11 features is more-or-less irrelevant - they have a set of real world compilers to support (or justify upgrade from) and so they would love clear statements about what compilers a particular library works on. Of course it is not trivial for an author to supply such a statement - bits of the library may require more modern c++ than other parts - or the minimum feature set required may be inherited from a library used internally by the implementation and this might also change from release to release...
I believe Stephen Kelly has posted on this list a couple of times about how CMake tries to address these issues.
If the modularisation of boost takes shape then if would be useful to have C++11 libraries NOT unnecessarily depend on the boost version of C++11 libraries in order to reduce dependencies. What’s your view on that? E.g. if I wanted to make a "boost C++11 random library” then that could build on top of the C++11 random lib instead of the boost random lib. This would reduce dependencies and make the library work standalone on a C++11 compiler.
On 24 Nov 2014 at 21:36, M.A. van den Berg wrote:
I believe Stephen Kelly has posted on this list a couple of times about how CMake tries to address these issues.
If the modularisation of boost takes shape then if would be useful to have C++11 libraries NOT unnecessarily depend on the boost version of C++11 libraries in order to reduce dependencies.
What´s your view on that?
Soon to be proposed Boost.BindLib can solve exactly that. You need to port your Boost library to BindLib, but after that BindLib lets you "templatise" your choice of C++ 11 STL, including within the current translation unit. I have AFIO ported to BindLib, and you can mash up, in the same compiland, any mix of the three substitutables (Thread-Atomic-Chrono, Filesystem, ASIO) you like. Indeed, one unit test compiles multiple "instantiations" of the AFIO unit tests into a single executable, and executes each variant of the unit tests in turn. Some on this list thought such a solution when I originally proposed it might be brittle, and I was also worried it might be so. It turns out to work surprisingly okay - all variants survive a 24 hour unit test soak without error. I think that is a huge testament to the quality of Boost and STL libraries, and also because namespace binds are merely simple aliases to real implementation so any type conflicts like trying to feed std::chrono to boost::chrono emerge readily at compile time.
E.g. if I wanted to make a "boost C++11 random library" then that could build on top of the C++11 random lib instead of the boost random lib. This would reduce dependencies and make the library work standalone on a C++11 compiler.
Soon to be proposed Boost.BindLib also provides a thin emulation of Boost.Test, so even your unit test suite can run standalone. My aim is for single header only standalone drop ins, so no requirements for any particular build system. Simply git clone the Boost submodule, include the header and off you go, though you probably will want to precompile that header for sane build times. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
If the modularisation of boost takes shape then if would be useful to have C++11 libraries NOT >unnecessarily depend on the boost version of C++11
M.A. van den Berg wrote: libraries in order to reduce dependencies.
What's your view on that?
E.g. if I wanted to make a "boost C++11 random library" then that could
build on top of the >C++11 random lib instead of the boost random lib. This would reduce dependencies and make the >library work standalone on a C++11 compiler. I want Boost to remain fresh and fertile. For me this means keeping the stream of people willing and able to contribute to Boost coming. Therefore I'd want to give authors a free hand, as much as possible. E.g. if a new library came along that needed a tuple facility, they should feel free to just use <tuple> / std::tuple rather than being obliged to template on tuple type (or more sophisticatedly, use the Boost.BindLib library that Niall says is around the corner), just in case someone is stuck with boost::tuple. If someone else is stranded on VS2005 (or whatever) and comes along with a patch to backport support to boost::tuple, then great. For existing libraries on the other hand, it seems wrong to break backwards-compatibility without a really good reason so if a library is c++98 now, why not leave it that way. If someone thinks a particular domain can be done better using c++11 facilities, then I think a "v2" of the library makes sense. Just 2c, Pete
On 24 Nov 2014 at 22:05, Pete Bartlett wrote:
I'd want to give authors a free hand, as much as possible. E.g. if a new library came along that needed a tuple facility, they should feel free to just use <tuple> / std::tuple rather than being obliged to template on tuple type (or more sophisticatedly, use the Boost.BindLib library that Niall says is around the corner), just in case someone is stuck with boost::tuple. If someone else is stranded on VS2005 (or whatever) and comes along with a patch to backport support to boost::tuple, then great.
Be aware that for the switchable underlying STL facility, BindLib absolutely requires template aliasing support in the compiler (otherwise he can't generate the binds from your library to either boost::tuple or std::tuple). And template aliasing is a C++ 11 feature, so your compiler needs to be C++ 11 mode. tuple, incidentally, is in the presupplied bindings, but I have absolutely no idea if it works. No reason it shouldn't, though.
For existing libraries on the other hand, it seems wrong to break backwards-compatibility without a really good reason so if a library is c++98 now, why not leave it that way. If someone thinks a particular domain can be done better using c++11 facilities, then I think a "v2" of the library makes sense.
One of BindLib's main goals is to solve the API and ABI versioning problem in all Boost libraries. Once a library enters Boost it is supposed to keep backwards API compatibility and optionally ABI compatibility, and doing this usually involves an awful lot of #ifdef which is a pain to debug and maintain. A BindLib based library lives in some unique namespace you don't need to care about as the binds and any inline namespace support in your compiler make that unique namespace not appear to code using your library. That way if I change AFIO to have a breaking API change, I can ship v1.2 of AFIO *and* v1.3 of AFIO and both versions coexist happily just as a Boost.Filesystem based AFIO coexists happily with a STL Filesystem based AFIO. Code using AFIO that is tied to particular version simply binds in a specific version of AFIO, and can carry on with that API version as long as it feels like, though probably without bug fixes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 24 Nov 2014 at 19:03, Pete bartlett wrote:
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less
I think it *is* worth asking "what's the point". For end users whether a particular library uses c++11 features is more-or-less irrelevant - they have a set of real world compilers to support (or justify upgrade from) and so they would love clear statements about what compilers a particular library works on.
I would hope any new C++ 11 only Boost libraries would be CI tested per commit on all the popular compilers, and I certainly would object to any Boost documentation without a clear statement of tested compilers (though I much prefer a realtime CI test dashboard like https://boostgsoc13.github.io/boost.afio/).
Of course it is not trivial for an author to supply such a statement - bits of the library may require more modern c++ than other parts - or the minimum feature set required may be inherited from a library used internally by the implementation and this might also change from release to release...
SG-10 are developing feature test macros. Pretty much all the compilers with C++ 14 features are adhering to them. Support is considerably more patchy for C++ 11 features, and MSVC currently refuses to support them at all. I have a header file which creates a consistent set of SG-10 feature test macros on all the three major compilers including older ones at https://github.com/ned14/Boost.BindLib/blob/master/include/cpp_feature .h. Some may find it useful. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Pete bartlett Sent: 24 November 2014 19:03 To: boost@lists.boost.org Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
On 24 Nov 2014, at 18:28, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On Mon, Nov 24, 2014 at 8:20 AM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
*snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less
I think it *is* worth asking "what's the point". For end users whether a
A part (admittedly decreasing) of Boost will still work on C++98. particular
library uses c++11 features is more-or-less irrelevant - they have a set of real world compilers to support (or justify upgrade from) and so they would love clear statements about what compilers a particular library works on. Of course it is not trivial for an author to supply such a statement - bits of the library may require more modern c++ than other parts - or the minimum feature set required may be inherited from a library used internally by the implementation and this might also change from release to release...
To try to provide this info is to try to build on quicksand - compilers are changing continuously and will continue to do - this for ever. Authors and macros give some clues, but the bottom line is "Does it compile?" Boost has also tried not to abandon old compilers unnecessarily, but not promised to provide workarounds, so if the author says C++YY only, then that's OK. I think that Boost has always said "Suck-it-and-see" and "YMMY", and should continue to be so. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
*snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less?
Sure, but what's the point of this? Is it discouraged to use old C style for() loops now? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Le 24/11/14 23:28, Hartmut Kaiser a écrit :
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list: *snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less? Sure, but what's the point of this? Is it discouraged to use old C style for() loops now?
;-) Hartmut, you have a rich experience with HPX and C++11 compilers. What are the things that were easier with a C++11 compiler/C++ STL library? Best, Vicente
Le 24/11/14 23:28, Hartmut Kaiser a écrit :
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list: *snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++11 *only*. (or more precisely >= C++11) ie won't work in anything less? Sure, but what's the point of this? Is it discouraged to use old C style for() loops now?
;-)
Hartmut, you have a rich experience with HPX and C++11 compilers. What are the things that were easier with a C++11 compiler/C++ STL library?
Many things are a lot easier with C++11/14, we all know that. But what is the point of creating a list of libraries _requiring_ a C++11 compiler? Code which does not use C++11/14 features is still compilable with modern compilers just fine. Also, it's still possible to use older code together with newer libraries. The only purpose I would see is to tell people which libraries they can't use if they are stuck with older compilers for some reason... Sorry I miss the point of this discussion and will shut up. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
On 24 Nov 2014 at 21:53, Hartmut Kaiser wrote:
Many things are a lot easier with C++11/14, we all know that. But what is the point of creating a list of libraries _requiring_ a C++11 compiler? Code which does not use C++11/14 features is still compilable with modern compilers just fine. Also, it's still possible to use older code together with newer libraries. The only purpose I would see is to tell people which libraries they can't use if they are stuck with older compilers for some reason...
Sorry I miss the point of this discussion and will shut up.
You may remember my C++ Now 2014 talk and white paper was exceedingly gloomy about Boost - lots of empirical trend graphs pointing at two year long trend declines and a fair bit of hyperbole from me about poisonous anti-change anti-innovation anti-process cultures etc. Six months later I'm feeling that something is changing, but I don't know what exactly or how profound it might be. In thinking about measurable proxies of change I could go examine, I can see that studying C++ 11 only Boost libraries could be considered a proxy for "green shoots" of new growth in Boost. Hence my hypothesis, and investigating that might yield an answer to whether Boost is going to resurge in a big way or something completely else. I appreciate it's a bit abstract. Hopefully when you're evaluating the C++ Now submissions it'll seem worthy to you then. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 24 Nov 2014 at 7:20, Hartmut Kaiser wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
*snipped list*
Technically, all libraries in Boost are C++11. What's your point?
C++ 11 *only* Boost libraries. As in, absolutely requires C++ 11 and cannot possibly work with less. What's the point? Well, given the theme of C++ Now 2015, I thought it might be interesting to do a quick overview of C++ 11 only Boost libraries which are at or nearing review. My current hypothesis is that there are probably three categories of C++ 11 only Boost library: Type 1: Could be or were implemented in C++ 03, but enormous gains in simplicity/maintenance costs/performance/utility was gained by a rewrite into C++ 11/14. Type 2: Would not be possible without C++ 11/14, as in, simply could not be implemented in C++ 03 no matter what. Type 3: Probably could be ported to C++ 03 with some effort and not especially terrible consequences, but hasn't happened yet/isn't the demand/couldn't be bothered. If this hypothesis is true, then what are the killer C++ 11/14 features in Type 1 libraries which have most commonly been used? For Type 2 libraries, are they self similar and all follow a theme, or are they completely different? As with last year, I was going to write up an academic paper on the topic, and present a 90 minute review of its findings during C++ Now. Some may find it interesting. I personally am looking forward to doing the empirical research if the talk is accepted, I think I am going to learn a thing or two. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 11/24/2014 03:10 AM, Niall Douglas wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
* Boost.Spirit X3 ETA to Boost review: unknown, last commit was June 2014.
Last commit was Oct 18th, 2015. <https://github.com/boostorg/spirit/tree/x3-devel> The requirement is C++14 or greater. I'm a little unsure what you are asking. Are you asking for libraries that require C++11 features? michael -- Michael Caisse ciere consulting ciere.com
On 24 Nov 2014 at 11:20, Michael Caisse wrote:
On 11/24/2014 03:10 AM, Niall Douglas wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
* Boost.Spirit X3 ETA to Boost review: unknown, last commit was June 2014.
Last commit was Oct 18th, 2015. <https://github.com/boostorg/spirit/tree/x3-devel>
Thanks hugely for the link. Google didn't help me there.
The requirement is C++14 or greater.
Is that enough C++ 14 only clang works, or does GCC work too?
I'm a little unsure what you are asking. Are you asking for libraries that require C++11 features?
Yes, though I am including C++14 in that. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 11/24/2014 01:11 PM, Niall Douglas wrote:
On 24 Nov 2014 at 11:20, Michael Caisse wrote:
On 11/24/2014 03:10 AM, Niall Douglas wrote:
<snip>
* Boost.Spirit X3 ETA to Boost review: unknown, last commit was June 2014.
Last commit was Oct 18th, 2015. <https://github.com/boostorg/spirit/tree/x3-devel>
Thanks hugely for the link. Google didn't help me there.
The requirement is C++14 or greater.
Is that enough C++ 14 only clang works, or does GCC work too?
GCC is working too. There is a work-around for a decltype compiler bug... but it is working. -- Michael Caisse ciere consulting ciere.com
Le 24/11/14 12:10, Niall Douglas a écrit :
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
...
I have to admit surprise at how long the list I have collected already is.
Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong?
There is also Boost Tick and Boost Fit. I don't know to what extent range-v3 could be considered in this list. I think you should extend the scope of your talk to libraries that need a c++14 compiler. I would expect more functional programming libraries coming soon.. Constexpr generic lambdas as so easy to write and compose :) Boost.Thread has some sub-libs that need a c++11 compiler. I'm tired to emulate the variadics and move semantics, I need some libraries in C++11 STL that are not available in Boost or c++03 STL. I don't know if I would have the time, but I planned long time ago to add UDL to chrono. Best, Vicente
On 24 Nov 2014 at 23:49, Vicente J. Botet Escriba wrote:
Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong?
There is also Boost Tick and Boost Fit. I don't know to what extent range-v3 could be considered in this list.
Good catch on Boost.Fit. I hadn't noticed it's C++ 11 only. Do you have a link to Boost.Tick, I cannot find it with Google?
I think you should extend the scope of your talk to libraries that need a c++14 compiler. I would expect more functional programming libraries coming soon.. Constexpr generic lambdas as so easy to write and compose :)
I won't rule out covering C++ 14 only libraries. However, right now as there is only one fully featured C++ 14 compiler I would suggest that "Boost readiness" must be low for C++ 14 only libraries as they cannot have been as well tested as libraries which work on all three of the major compilers. As much as everyone finds porting modern C++ to MSVC a pain, I still think it's good for you as an engineer and it's good for your code.
Boost.Thread has some sub-libs that need a c++11 compiler. I'm tired to emulate the variadics and move semantics, I need some libraries in C++11 STL that are not available in Boost or c++03 STL.
I hope to return to working on Expected sometime after Christmas, and to integrate it with non-allocating future-promise along the constexpr resumable monadic continuations design I outlined on this list some weeks ago. Sorry about the lack of progress Vicente. Unfortunately I am consumed with higher priority items right now (BindLib, then KernelAlloc) as these are immediate showstoppers for my work colleagues. I do appreciate the inconvenience for you however. BTW Vicente we may need to ponder how to "do" submodules for Thread. Do we simply add git submodules wherever we feel like? Do we implement some form of module organisation e.g. all submodules live in a special directory? How does the build system detect submodules, and how should config.hpp reflect them? These are all good questions if Thread is going to gain a lot of submodular components as currently seems inevitable - even my non-allocating future promise will on its own drag in three separate git submodules currently. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Nov 25, 2014 at 1:39 PM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
I won't rule out covering C++ 14 only libraries. However, right now as there is only one fully featured C++ 14 compiler I would suggest that "Boost readiness" must be low for C++ 14 only libraries as they cannot have been as well tested as libraries which work on all three of the major compilers.
One does not need a 'full' C++14 compiler to start using C++14 features..
On 2014-11-24 12:10, Niall Douglas wrote:
For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list:
Since you are including not-yet-Boost libraries: I currently plan to request a Boost review for sqlpp11 in 2015. Currently it requires C++11, but I plan to submit a version that will require C++14 plus ConceptsLite. Best, Roland
I have to say I don't get the point of such a review. Boost has never had a requirement that a library support anything other than the latest available C++ standard. Given that C++11+ has facilities that make library writing easier (especially for more difficult libraries), I would expect that almost any library not in Boost would be built using C++11+ facilities. So what is the point of making such a list? C++ libraries are defined by their public interfaces. The implementation is (or should be) irrelevant to the user. Since C++ evolution places high value on maintaining backward compatibility, Users shouldn't see any effects from the emergence of any C++11+ version. Again, I just don't see what the point of such a review would be? How would it be useful or relevant to any user or library developer? I know you've got lot's of interesting ideas. You might want to pick a different one to give a talk on. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/List-of-C-11-only-Boost-libraries-and-the... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 11/26/2014 10:51 AM, Robert Ramey wrote:
I have to say I don't get the point of such a review.
Boost has never had a requirement that a library support anything other than the latest available C++ standard.
Given that C++11+ has facilities that make library writing easier (especially for more difficult libraries), I would expect that almost any library not in Boost would be built using C++11+ facilities. So what is the point of making such a list?
C++ libraries are defined by their public interfaces. The implementation is (or should be) irrelevant to the user. Since C++ evolution places high value on maintaining backward compatibility, Users shouldn't see any effects from the emergence of any C++11+ version. Again, I just don't see what the point of such a review would be? How would it be useful or relevant to any user or library developer?
The C++ standard used by a library is actually very relevant to users, especially for template libraries. If the user has a requirement to use an older compiler that doesn't support C++11/14, then template libraries that use those dialects, even just in their implementation, are not usable. Even for non-template libraries, where the user just compiles against a set of headers and links against a provided binary, the C++ dialect used when compiling the library is important. There's no airtight guarantee of ABI compatibility between the C++11 and C++98/03 standard libraries, so you can run into problems if, for instance, the layout of a std::list<T> differs between the two standard library implementations (as it could because of the change in complexity of std::list<T>::size() between the two C++ versions). So, from the perspective of a user who is often limited to use older compilers, the language requirements of a library that I'm considering is very important. Jason
On Wed, Nov 26, 2014 at 10:51 AM, Robert Ramey <ramey@rrsd.com> wrote:
I have to say I don't get the point of such a review.
Boost has never had a requirement that a library support anything other than the latest available C++ standard.
Yet, there's lots of "muck" in many boost headers to support ancient compilers, and (I assume) there exists users that are grateful for that muck, as it means they can use boost in their codebases that are, for whatever reason, stuck using older compilers. For example, some people use boost::shared_ptr because they don't have std::shared_ptr. Much of boost is in C++11, so much of boost has successfully obsoleted itself!, other than for users stuck in the past. A portion of boost is used precisely because it is NOT C++11. The real question is what percentage of the boost community has upgraded their compilers to C++11 or greater. And what might this say for C++11 adoption in general. And what does that say about boost moving forward - which users are we trying to help? And, the reverse question (which Niall is asking), how much of Boost has moved to C++11 or greater, even if a large(?) percentage of the community hasn't. And if so, what does that say about Boost and/or C++ adoption. ie is Boost pushing the adoption of C++11? Would boost push C++11 better if its libraries were backwards compatible (so as to "ease" people into C++11) or should a library abandon old C++ and "force" users to move forward? If I was to write a new library, that _could_ be old-C++ compatible, but with extra work, should I put in that extra work? I think there are interesting questions here for Boost and C++. Not sure if Niall is heading towards those questions or others. --- The further question, which I think should be discussed here or at BoostCon/C++Now, is what is Boost's role *today*? Is boost still a stepping stone to the standard? (I find that with the standard's new pace, and with its push to use TS's, "stepping stone" is now a more minor role for boost. For better or worse - ie I'm not sure if it is good for the standard.) Or is boost now a place for good libraries, most of which aren't general enough to be in std, but are really good and really useful when you need them? Or is boost a maintenance effort for old libraries for older compilers. (I don't think Boost is just that, but is it part of its role?) Tony
Gottlob Frege wrote
And, the reverse question (which Niall is asking), how much of Boost has moved to C++11 or greater, even if a large(?) percentage of the community hasn't.
I agree that that is the question being asked. I just don't think any answer will change anything.
If I was to write a new library, that _could_ be old-C++ compatible, but with extra work, should I put in that extra work?
Of course that's up to the author. Boost has never required this and it's been noted in various places that this is not a requirement for a library to get accepted. It's been sufficient for any new library that it work with the current standard. People using older compilers are mostly maintaining old code. I doubt they really need new libraries. And writing for the current standard is soooo much easier.
I think there are interesting questions here for Boost and C++. Not sure if Niall is heading towards those questions or others.
Agreed
The further question, which I think should be discussed here or at BoostCon/C++Now, is what is Boost's role *today*? Is boost still a stepping stone to the standard? (I find that with the standard's new pace, and with its push to use TS's, "stepping stone" is now a more minor role for boost. For better or worse - ie I'm not sure if it is good for the standard.) Or is boost now a place for good libraries, most of which aren't general enough to be in std, but are really good and really useful when you need them? Or is boost a maintenance effort for old libraries for older compilers. (I don't think Boost is just that, but is it part of its role?)
Of course this is the key question. My views on these questions are pretty simple a) The C++ world needs many more good libraries b) Adding many more libraries to the standard is not sustainable c) Therefore, the role of boost should shift away to making libraries for the standard toward making good C++ libraries in general. -- View this message in context: http://boost.2283326.n4.nabble.com/List-of-C-11-only-Boost-libraries-and-the... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Thu, Nov 27, 2014 at 11:12 PM, Robert Ramey <ramey@rrsd.com> wrote:
Gottlob Frege wrote
The further question, which I think should be discussed here or at BoostCon/C++Now, is what is Boost's role *today*? Is boost still a stepping stone to the standard? (I find that with the standard's new pace, and with its push to use TS's, "stepping stone" is now a more minor role for boost. For better or worse - ie I'm not sure if it is good for the standard.) Or is boost now a place for good libraries, most of which aren't general enough to be in std, but are really good and really useful when you need them? Or is boost a maintenance effort for old libraries for older compilers. (I don't think Boost is just that, but is it part of its role?)
Of course this is the key question. My views on these questions are pretty simple
a) The C++ world needs many more good libraries b) Adding many more libraries to the standard is not sustainable c) Therefore, the role of boost should shift away to making libraries for the standard toward making good C++ libraries in general.
I agree with c). IMO to facilitate that we need to move away from the monolithic codebase identity of boost and shift towards a repository of "boot-style reviewed and documented libraries" that are separately downloadable. If we allow for many libraries (e.g. 500) then we should allow for all 3 libraries "sort" and a "algorithms" and a "radixsort" (to pick a recent discussion) to live side-by-side because overlap like that are bound to happen with 500 libraries. I see that happen in other languages that have many libraries like python, R, and it's no problem. Allowing for overlap also makes it more clear that boost is no longer monolithic codebase. It also makes things easier for library developers. Regarding the support for old compilers: in front-end web development you have "normalization" libraries (eg http://necolas.github.io/normalize.css/) that try to make webpages work and look the same on all types of browser. In earlier discussion normalization has been part of an idea called a "core" library but it could be a standalone library that focuses on compatibility and compiler support.
Gottlob Frege wrote
And, the reverse question (which Niall is asking), how much of Boost has moved to C++11 or greater, even if a large(?) percentage of the community hasn't. I agree that that is the question being asked. I just don't think any answer will change anything.
If I was to write a new library, that _could_ be old-C++ compatible, but with extra work, should I put in that extra work? Of course that's up to the author. Boost has never required this and it's been noted in various places that this is not a requirement for a library to get accepted. It's been sufficient for any new library that it work with the current standard. People using older compilers are mostly maintaining old code. I doubt they really need new libraries. And writing for the current standard is soooo much easier. Agreed. I think there are interesting questions here for Boost and C++. Not sure if Niall is heading towards those questions or others.
The further question, which I think should be discussed here or at BoostCon/C++Now, is what is Boost's role *today*? Is boost still a stepping stone to the standard? (I find that with the standard's new pace, and with its push to use TS's, "stepping stone" is now a more minor role for boost. For better or worse - ie I'm not sure if it is good for the standard.) Or is boost now a place for good libraries, most of which aren't general enough to be in std, but are really good and really useful when you need them? Or is boost a maintenance effort for old libraries for older compilers. (I don't think Boost is just that, but is it part of its role?) Of course this is the key question. My views on these questions are pretty simple
a) The C++ world needs many more good libraries Agreed. I would like so see something like your incubator as a repertory of independent C++ libraries. One thing we need are versioned libraries with its explicit dependencies. The other is a way to install them on
Le 27/11/14 23:12, Robert Ramey a écrit : the user work space.
b) Adding many more libraries to the standard is not sustainable Why do you think this? The standard committee is asking permanently for more contributors, more libraries. There is so much to add. This doesn't mean that this doesn't takes time. c) Therefore, the role of boost should shift away to making libraries for the standard toward making good C++ libraries in general.
I would like to see more Boost libraries proposed for the standard. Your Serialization library would surely have a good feedback, once it is adapted to C++14. I would like to see a Boost C++14 libraries with much of the current Boost libraries ported to C++14, removing all adherences to old compilers. Only in this case we can pretend yet that Boost could be a trampoline to concrete standard proposal. C++14 and C++98 are so different. This C++14 library should be modular and the user should be able to install each library independently. Best, Vicente
Vicente Botet wrote
a) The C++ world needs many more good libraries
Agreed. I would like so see something like your incubator as a repertory of independent C++ libraries. One thing we need are versioned libraries with its explicit dependencies. The other is a way to install them on the user work space.
Agree on all points. Note that the incubator includes information for each library such as first order dependencies and library version #. Currently these are only "documentation" and not enforced in by me or in code. But if the incubator is successful, I would hope to see it evolve to use these fields in a more formal way. In boost we are currently having working on (and having difficulty with) dependency managment. We don't yet have any formal requirements for library versions (vs boost versions) - but I think we will have to move there eventually. I see this as another step in boost modularization.
b) Adding many more libraries to the standard is not sustainable
Why do you think this? The standard committee is asking permanently for more contributors, more libraries. There is so much to add. This doesn't mean that this doesn't takes time.
I'm just looking at the numbers. I'm hypothesizing 500 libraries. I just picked the number 500 out of thin air. The point is that it's a number that I don't think the current standards process can handle and I think that it's a number that compiler vendors cannot be expected to deliver. If 500 libraries are added to the standard, then no vendor wil deliver the whole thing. Then what does it mean to be part of the standard?
c) Therefore, the role of boost should shift away to making libraries for the standard toward making good C++ libraries in general.
I would like to see more Boost libraries proposed for the standard. Your Serialization library would surely have a good feedback, once it is adapted to C++14.
I would like to see a Boost C++14 libraries with much of the current Boost libraries ported to C++14, removing all adherences to old compilers. Only in this case we can pretend yet that Boost could be a trampoline to concrete standard proposal. C++14 and C++98 are so different.
Agreed - but these tasks entail a huge amount of work - who is going to pay for this? Re-defining serialization for C++14, making a compliant implementation for review, writing the standardese, and having compiler vendors code up their own versions would be a huge amount of work - and who pays for this? And what value is in it? What would it add that we don't already have. I confess that I've never been sold on the concept of a standard library implementation - at least to the extent that it has grown to. I've questioned my convictions when someone pointed out to me that boost was embraced by many institutions only when parts of it got added to the standard library. This made it possible to use without getting blamed when something problematic came up.
This C++14 library should be modular and the user should be able to install each library independently.
YES! YES! ... BUT - this is not quite so simple as it may appear. I've become skeptical of ambitious efforts such as rypll and others. On the other hand, I'm seeing that git hub is being used to good advantage by users of the incubator. At least I haven't had complaints from users that they can't download and test any of the libraries there. I'm thinking that things evolve where the modular boost directory structure becomes sort of "standard" any other libraries can be just cloned and a simple "b2 headers" can be run (maybe not even that). And there is the dependency issue again. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/List-of-C-11-only-Boost-libraries-and-the... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 28 Nov 2014 at 11:15, Robert Ramey wrote:
In boost we are currently having working on (and having difficulty with) dependency managment. We don't yet have any formal requirements for library versions (vs boost versions) - but I think we will have to move there eventually. I see this as another step in boost modularization.
FYI BindLib implements API and optional ABI version management. You use binds to hard bind a specific dependency to a specific API version. Different libraries in the same translation unit can bind to different versions of the same dependency. For dependency management, you're probably not going to like my solution as I don't either, but essentially you git submodule all your library dependencies into your include directory, so library/include/boost/library/submodule. You then go ahead and use them directly, so instead of: #include "boost/spinlock/spinlock.hpp" you do: #include "spinlock/include/boost/spinlock/spinlock.hpp" You probably now wonder isn't this very wasteful having every Boost library keep its own git submodules of other boost libraries? Well, it turns out that git spots you doing that, and only keeps a single copy of every git submodule no matter how frequently used. Therefore, this solution lets your library run standalone AND correctly "symlink" to the appropriate Boost library when being used from within Boost. The only cost is much increased checkout disc space really and that it takes a good while longer to submodule update, and I'm sure some future actual symlink solution as part of b2 headers could fix that too. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote
For dependency management, you're probably not going to like my solution as I don't either, but essentially you git submodule all your library dependencies into your include directory, so library/include/boost/library/submodule. You then go ahead and use them directly, so instead of:
#include "boost/spinlock/spinlock.hpp"
you do:
#include "spinlock/include/boost/spinlock/spinlock.hpp"
Well for once we do agree - I don't like it either! Right now we have all the boost library modules in a "flat" list at the same level of the library / application I'm working on. Rather than using b2 headers to create a monolithic head structure from our modules we could just as well replace #include <boost/spinlock/spinlock.hpp> with (assuming we're in side of libs/serialization/* (test, library or example) #include <../../spinlock/include/boost/spinlock/spinlock.hpp> or just add all the ../../*/include/ paths to the include search path. Then there is the redundant "boost" I'd like to eliminate - but much too disruptive for now. Personally, I'm at about the limit of git complexity I can currently deal with Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/List-of-C-11-only-Boost-libraries-and-the... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 28 Nov 2014 at 13:19, Robert Ramey wrote:
Niall Douglas wrote
For dependency management, you're probably not going to like my solution as I don't either, but essentially you git submodule all your library dependencies into your include directory, so library/include/boost/library/submodule. You then go ahead and use them directly, so instead of:
#include "boost/spinlock/spinlock.hpp"
you do:
#include "spinlock/include/boost/spinlock/spinlock.hpp"
Well for once we do agree - I don't like it either!
If anyone can suggest *any*, any at all better solution I am genuinely all ears. It has to work standalone/modular as well as within the collective Boost.
Right now we have all the boost library modules in a "flat" list at the same level of the library / application I'm working on.
I am already running into surprises from nested git submodules. For example, AFIO is dependent (in develop branch) on BindLib and Expected and Spinlock. Each of Expected (my branch) and Spinlock is also dependent on BindLib, but Spinlock is also dependent on Expected which is again dependent on BindLib. That turns into four nested copies of BindLib. I somehow find that objectionable, even though they're all the same copy :(. But I cannot think of a better way unfortunately. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 11/28/2014 08:15 PM, Robert Ramey wrote:
I confess that I've never been sold on the concept of a standard library implementation - at least to the extent that it has grown to. I've questioned my convictions when someone pointed out to me that boost was embraced by many institutions only when parts of it got added to the standard library. This made it possible to use without getting blamed when something problematic came up.
Here is another motivation: Howard Hinnant's std proposal "N3980: Types Don't Know #" is basically a reinvention of the serialization technique, but limited to hash functions. So something less generic could enter into C++17 unless someone suggests something more generic. Regarding upgrading Boost.Serialization to C++14, you could start by looking at Cereal, which is a C++11 reimplementation of Boost.Serialization: http://uscilab.github.io/cereal/
Bjorn Reese wrote
Regarding upgrading Boost.Serialization to C++14, you could start by looking at Cereal, which is a C++11 reimplementation of Boost.Serialization:
Of course I've looked at this - at least the documentation and github page. It looks interesting. I think the Cereal webpage and documentation downplays the importance of a number of features they chose not to implement. It's very hard to make a real comparison without trying to use it in a real, complex project. On the other hand, if one wanted to add something to the standard, doing something smaller and simpler than Boost serialization might be good idea. On the other hand, remember why boost (and standard) libraries get so elaborate,comprehensive and (therefore complicated) in the first place. It's because review committees have members with widely varying visions and to make through the gauntlet requires adding in just about everything but the kitchen sink. This is one reason why I have a lot of reservations about the whole concept of of the "standard library". Maybe the world is a better place if it has room for various serialization libraries which implement similar ideas but with different choices and compromises. A standard library can't do this. We'll keeping an eye on it. -- View this message in context: http://boost.2283326.n4.nabble.com/List-of-C-11-only-Boost-libraries-and-the... Sent from the Boost - Dev mailing list archive at Nabble.com.
On November 30, 2014 12:30:57 PM EST, Robert Ramey <ramey@rrsd.com> wrote:
Bjorn Reese wrote
This is one reason why I have a lot of reservations about the whole concept of of the "standard library". Maybe the world is a better place if it has room for various serialization libraries which implement similar ideas but with different choices and compromises. A standard library can't do this.
Once there's a standard version of something, people get comfortable using it because it's available as a default. When that proves insufficient, they start looking for something better elsewhere. That means getting something decent, but not ideal, in the Standard can jumpstart things. ___ Rob (Sent from my portable computation engine)
I believe people would care less if a library is standard or not if there was an easy way to get the library and integrate it in a project. Most Python and Ruby users have no reluctance into trying a library because it's so easy to plug one in by copy/paste or by using pip or gem. Having a standard library that only provide essential necessities would be tolerable in such a context. The other issue with standardising a library is that it seem insanely hard to update it later for fixes.
On Mon, Dec 1, 2014 at 11:13 AM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I believe people would care less if a library is standard or not if there was an easy way to get the library and integrate it in a project. Most Python and Ruby users have no reluctance into trying a library because it's so easy to plug one in by copy/paste or by using pip or gem.
I think you're right and this is especially problematic on Windows (IMO). Building is a nightmare, it'd be awesome if there was a good solution for this. On Linux one can often just do apt-get / yum install <lib> -- Olaf
On Thu, Nov 27, 2014 at 5:12 PM, Robert Ramey <ramey@rrsd.com> wrote:
People using older compilers are mostly maintaining old code. I doubt they really need new libraries.
I hope that presumption doesn't drive any policy decisions regarding the future of Boost. Our product uses just short of 50 third-party library packages (one of which contains several Boost libraries). The ABI problem means that in practice, to upgrade to a newer compiler, we must rebuild all those packages with the new compiler. I need hardly mention that the idiosyncratic build scripts for each package need iterative tweaking to produce clean builds with the new build system. That's quite aside from the C++ source changes required by compiler evolution. Given that, I am very happy that this year my organization committed the resources to update to newer compilers on Windows and Mac. It's taken us three months. Although I personally consider our code base fairly large, I realize that a large organization would consider it laughably trivial. It's all too easy to understand that with a larger code base, or different management, such an effort might never have gotten a green light: we'd have remained stuck on pre-C++11 compilers. Yet our product is under active development. We continue to add new features and refactor existing code. We recently added a couple more third-party libraries. I am keeping a keen eye on the Boost library suite. I do not believe that Boost should require C++03 support for new libraries. As has been pointed out, the barrier for entry to Boost is already quite high. I'm just contradicting the assumption that those who must work with old compilers aren't doing any new development, or have no interest in new libraries.
On Sat, Dec 13, 2014 at 8:27 AM, Nat Goodspeed <nat@lindenlab.com> wrote:
I'm just contradicting the assumption that those who must work with old compilers aren't doing any new development, or have no interest in new libraries.
To add to this point, I would like to mention that even new developments trends might require support to old or limited compilers. E.g.: IoT, real time projects, industrial HMIs and mobile applications. Roger
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gottlob Frege Sent: 27 November 2014 21:26 To: boost@lists.boost.org Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
On Wed, Nov 26, 2014 at 10:51 AM, Robert Ramey <ramey@rrsd.com> wrote:
I have to say I don't get the point of such a review.
Boost has never had a requirement that a library support anything other than the latest available C++ standard.
I'm not sure it has even had that - Are any compilers really fully compliant with any standard even now? Is any standard really that fully defined?
Would boost push C++11 better if its libraries were backwards compatible (so as to "ease" people into C++11) or should a library abandon old C++ and "force" users to move forward?
No - not gratuitously.
If I was to write a new library, that _could_ be old-C++ compatible, but with extra work, should I put in that extra work?
The further question, which I think should be discussed here or at BoostCon/C++Now, is what is Boost's role *today*? Is boost still a stepping stone to the standard? (I find that with the standard's new pace, and with its push to use TS's, "stepping stone" is now a more minor role for boost. For better or worse - ie I'm not sure if it is good for the standard.) Or is boost now a place for good
Only a little extra work. Sometimes it is trivial, when it would increase potential users to the many stuck with old compilers. libraries,
most of which aren't general enough to be in std, but are really good and really useful when you need them? Or is boost a maintenance effort for old libraries for older compilers. (I don't think Boost is just that, but is it part of its role?)
FWIW, I think it is still both - but the balance may be shifting. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 27 Nov 2014 at 16:26, Gottlob Frege wrote:
And, the reverse question (which Niall is asking), how much of Boost has moved to C++11 or greater, even if a large(?) percentage of the community hasn't.
If you would replace that choice of wording with "how much of _new boost development_ has moved to C++11 or greater ..." then I am in complete agreement.
And if so, what does that say about Boost and/or C++ adoption. ie is Boost pushing the adoption of C++11? Would boost push C++11 better if its libraries were backwards compatible (so as to "ease" people into C++11) or should a library abandon old C++ and "force" users to move forward?
If I was to write a new library, that _could_ be old-C++ compatible, but with extra work, should I put in that extra work?
I think there are interesting questions here for Boost and C++. Not sure if Niall is heading towards those questions or others.
I'm not sure if I'm heading towards those questions either, mainly because I don't think myself competent to judge right now. Currently right now I am intending to simply do a review and report of libraries close to ready for community review at C++ Now 2015. If during the preparation for that presentation I feel there is a bigger picture there I probably would pivot, but I am currently thinking that such synthetic analysis is better done in 2016 after a bit more reflection.
The further question, which I think should be discussed here or at BoostCon/C++Now, is what is Boost's role *today*? Is boost still a stepping stone to the standard? (I find that with the standard's new pace, and with its push to use TS's, "stepping stone" is now a more minor role for boost. For better or worse - ie I'm not sure if it is good for the standard.) Or is boost now a place for good libraries, most of which aren't general enough to be in std, but are really good and really useful when you need them? Or is boost a maintenance effort for old libraries for older compilers. (I don't think Boost is just that, but is it part of its role?)
I'm of the opinion, much to the annoyance of some on the committee, that the current transference of new library forms to std::experimental under the aegis of WG21 is unsustainable and inevitably doomed to fail. I think it will yield huge gains initially, but cannot work well over time simply because library design by committee very rarely works well in the long run. In my opinion, the correct and proper way of doing new standard library design is through attracting and retaining a substantial user base in a competitive market place of libraries. That is what made Boost popular and unique in the first place - it offered tools which other libraries, including the STL, aspired to. My current employment has me work regularly with ASIO and the ASIO way of thinking about concurrency as epitomised by N4045. I find much disagreeable about that whole way of thinking about concurrent design, but I would never claim it isn't battle hardened and proven good. As much as how ASIO does things is ugly, it is very effective and not far from ideal efficiency when designed around its assumptions [1]. This does present me a quandry though. If I had to vote on something like N4045 entering the standard my gut says vote no because I think we can do a lot better. But don't get me wrong, N4045 is currently the only game in town remotely approaching standards quality readiness through actual empirical practice rather than ivory tower top down deesign [1]. And if I were on the committee, I'd probably end up voting yes precisely because it is the only game in town. Niall [1]: ASIO's design is "zero copy to the kernel" rather than "zero copy to the NIC DMA engine" where the overwhelming problem child is Linux, as OS X and FreeBSD and Windows "do the right thing" with zero copy DMA if ASIO is properly prodded with 4k aligned no-COW scatter-gather buffers. Much of why Linux is that problem child is due to Linus personally himself, but we'll skip that for now (search google if you want to know more). Suffice it to say that Linux provides proprietary syscalls, and ASIO does not use them, but it probably wouldn't require too much effort to construct a framework where ASIO /could/ invoke proprietary Linux syscalls if certain additional restrictions were placed on ASIO using code. I may have some facilities regarding this in proposed Boost.KernelAlloc, but if benchmarking doesn't show enormous performance benefits I am inclined to consign Linux to second tier support status to be honest, I don't see the payback for the maintenance overhead for a special code path just for Linux alone here. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (24)
-
Andrzej Krzemienski -
Bjorn Reese -
Gottlob Frege -
Hartmut Kaiser -
Jason Roehm -
Klaim - Joël Lamotte -
Kris -
Krzysztof Jusiak
-
M.A. van den Berg -
Mathias Gaunard -
Michael Caisse -
Nat Goodspeed -
Niall Douglas -
Olaf van der Spek -
Oliver Kowalke -
Paul A. Bristow -
Pete bartlett -
Pete Bartlett
-
Rob Stewart -
Robert Ramey -
Rogerio dos Santos -
Roland Bock -
Thijs van den Berg
-
Vicente J. Botet Escriba