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/

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

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 // bind interface to implementation ); injector.create().run(); // construct hello world and run it // manual dependency injection auto writer = make_unique(); 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 18:28, Gottlob Frege wrote:

On Mon, Nov 24, 2014 at 8:20 AM, 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*. (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 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/

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/

-----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 wrote:

On Mon, Nov 24, 2014 at 8:20 AM, 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*. (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

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

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 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

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 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

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.

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

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/

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/

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:

http://uscilab.github.io/cereal/

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.

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 Thu, Nov 27, 2014 at 5:12 PM, Robert Ramey 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.

-----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 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