Re: [boost] Questions about upcoming review of Boost.AFIO

Subject: Re: [boost] Questions about upcoming review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-21 05:50:06

On 21 May 2015 at 9:57, Gonzalo BG wrote:

> >  I am unaware of anyone using AFIO in production code.
> 
> This is how I see it: your library might be included in a Boost release
> almost in 2016.

More like 2017 assuming a conditional acceptance. I have very little 
free time.

> Those who need asynchronous file i/o
> on already existing VS2013 projects are already doing "their own thing".

To be honest, VS2013 is usually far too new for most in this niche. 
They need more like VS2005 support, or earlier. They also generally 
want a C API, not a C++ API. This is my motivation for Microsoft COM 
bindings, and thence a C API wrapper. libuv is great, but I believe 
AFIO is better.

> Two years ago
> this might have made sense to some people (I know it did not make sense to
> some), but right now I think it is worth asking:
> 
> Do you happen to know of any particular VS2013 project willing to do this?

I'm not sure I understand the question? Willing to do what?

> To me the single most important thing is that _you_ are going to be
> maintaining this library for the next 10 years if it gets accepted.
> Having to maintain a library filled with macros and hacks for the sake of
> old compiler support is painful enough.
> Having to do this twice for 2 different APIs is a lot of work.

I'm actually pretty happy with the lack of macros and hacks in the 
v1.3 engine. All that portability layer stuff is abstracted into 
APIBind.

I also fully expect to support the present API, or a close variant, 
permanently as it's the ABI stable API. In other words it's the only 
API in AFIO ever marked up with BOOST_AFIO_DECL for DLL export.

> So I wish that you would focus on the API you want to have with the hope
> that this will keep you motivated longer and the
> whole community will benefit more in the long term.
> 
> From what I understood, a different interface for VS2013 can be provided
> either as an extension, or as a different library.
> Such a library/extension doesn't even need to be part of Boost if you don't
> want it to, and maybe those willing to use your library
> with VS2013 might take over the maintenance of this extension giving you
> time to work on other things.

I did an informal poll at C++ Now of those working with MSVC at their 
day jobs, some deploying at a very large scale. A very large number 
currently target VS2005, indeed many said it was the most stable MSVC 
in the past decade which is why they settled on it (and why not, it's 
a very good C++ 03 compiler). Their plans, overwhelmingly, are a jump 
from VS2005 straight to VS2015 with no intervening MSVC. Their tests 
on VS2015 RC have had excellent stability and often a substantial 
improvement in performance, and in most cases their clang/GCC C++ 
11/14 code paths work well on VS2015 without much work.

As much as VS2013 is a fine compiler, VS2015 is enormously better 
again.

> TL;DR: cut out all of the C++11 legacy code and save your future self a lot
> of time: require clang 3.7, C++14, and submit a minimal
> library that you are willing to maintain for the next 10 years.
> 
> Best regards and keep up the good work,
> I can't wait to see those constexpr futures in action!

The only expected major breaking change in the current API is the 
replacement of standard futures with the custom future. The custom 
future can return a T, an error_code, or an exception_ptr. With 
standard futures the error_code is encapsulated as a system_error.

I certainly can see that the community might demand a "finished" API. 
But firstly when is anything ever "finished"? And secondly, I believe 
I can convert the async_io_op struct over to an afio::future<T> 
standin type now before review begins, the afio::future<T> won't be 
the eventual implementation, but it would mean that the API is 
"finished" and ready for review.

That's currently where I am heading mentally. And thank you community 
for your feedback.

Niall

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