Re: [boost] Some statistics about the C++ 11/14 mandatory Boostlibraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boostlibraries
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-05-14 23:01:15

On Thu, May 14, 2015 at 5:29 PM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 14 May 2015 at 16:23, Emil Dotchevski wrote:
>
> > I think that if the option is available at all it should be up to
> > boost::function to map to std::function, but other Boost libraries would
> > still #include "boost/function.hpp" and refer to it as boost::function.
>
> The problem with that is almost certainly some libraries will need
> refactoring to support std::function. It's not always a clean swap,
> especially if boost::function extensions are used (even if not
> necessary).
>

I bet that there aren't that many examples of this.

I also wonder to what degree does anyone care that they have a mixture of
e.g. std::function and boost::function in their code base. I'm probably
biased because our corporate code base uses Boost and not std -- simply
because using Boost makes our code more portable. I keep thinking that
maybe at some point I'll switch everything to std but the way it's going, I
don't see this happening within the next 3-5 years.

> APIBind enables you to bind a copy of function<> into your library's
> namespace e.g.
>
> namespace boost { namespace foo { template<class R, class... Args>
> using function = std::function<R(Args...)>; } }
>
> You obviously wouldn't define that except when building under C++ 11
> with std function enabled. function<> then resolves to either std
> function or boost function as configured. Your library code is
> unchanged, and doesn't care what the implementation is.
>

Would this work in case a header only declares shared_ptr, as in:

namespace boost { template <class> class shared_ptr; }

instead of

#include <boost/shared_ptr.hpp>

?

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode