Re: [boost] List of C++ 11 only Boost libraries and their status?

Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-11-25 07:39:48

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/