Re: [boost] [AFIO] Review (or lack of it)

Subject: Re: [boost] [AFIO] Review (or lack of it)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-29 09:44:34

On 29 Aug 2015 at 5:52, Jeremy Maitin-Shepard wrote:

> I understand that it is already supported, and I agree that it is great to
> be able to pin to the current version (V2) and have assurances that it will
> work, and this will also be useful once there is a V3.  It is just the
> actual support for V1 that doesn't seem to serve any purpose, since my
> understanding is that there aren't any users of it.  Please correct me if
> I'm wrong.

If a v1 were not in there, I would be hearing complaints that there 
is no demonstration of this feature in action and without such a 
demonstration I cannot claim the feature in the documentation.

I am sure you can see I cannot win here: nobody is happy.

For the record, I intend to remove v1 when v3 is released. Until 
then, v1 works very well and is a well tested, reliable 
implementation.

> I very much like that AFIO can interoperate with either different library
> variants, but making the API and ABI depend on so many different
> configuration choices has its own drawbacks.  Is there a way, for instance,
> to make the library simultaneously interoperate with both filesystem TS
> paths and boost filesystem paths?  Similarly for Boost future vs. C++11
> std::future.

Such interoperation comes down to the willingness of the maintainers 
of those Boost libraries.

I do have some control over the futures interoperation as I control 
the lightweight futures library. As lightweight futures allow you to 
mix together any custom future type, you can compose some but not all 
waits from across multiple incompatible configurations of AFIO. Past 
that, there is unfortunately very little I can do.

Personally speaking I would find it very useful if Boost's STL 11 
facilities understood the C++ 11 STL equivalents. For example, 
std::error_code could convert into boost::error_code, 
std::filesystem::path could convert into boost::filesystem::path and 
so on. But all that is a separate issue to AFIO or APIBind.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/