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/