On 11 Feb 2016 at 18:00, Emil Dotchevski wrote:
Outcome is a very large part of achieving this very lightweight AFIO v2 whilst leveraging as much of the power of C++ as possible in doing so. I personally speaking think such lightweightness is overkill for the use cases as file i/o is enormously heavy, but I defer to Boost peer review judgement. You'll get what you collectively asked for. I don't personally agree with it, but if one *has* to write this sort of lightweight C++, then I think Outcome a great help in doing so.
I'm not qualified to judge these design decisions, but I'm very skeptical. You as the author of AFIO are an expert in this domain, or else you wouldn't be writing this library. It's okay to defer to peer review judgement as long as it is substantiated.
As I said during the peer review, people who think they want async file i/o are generally disappointed. What people really want is *control* which normally means low worst case latencies, but in the filing system synchronous i/o is almost always lower worst case latency than async so firing 10,000 threads at a file i/o problem might actually be sensible. AFIO v1 delivered oodles of control, but packed very substantial work into file open and close (both of which are horribly slow anyway so it made sense) in order to keep everything else fixed overhead. Now, I can totally see that if you want to open and close a lot of files, AFIO v1 is going to be not great for you, and v2 is going to be a lot better. People got upset with the find regex in files performance for example, and that was understandable: AFIO v1 is a poor choice for that use case. In this sense the v2 design is much more flexible and reusable, but the end user programmer will have to work far harder than with v1 and have a far deeper understanding of filing systems to get reasonable results. The single biggest reason I won't be presenting v2 for peer review is the enormous documentation which would be required, it's at least six months of work and probably more, and I just can't afford such an enormous loss of income. Still, what I learned from the Boost peer review is people here hate to be hand held, and I get that. And let me be very clear, the AFIO v2 design has a lot of merit, I don't disagree with any of it, I just think it excessive for its likely use cases - it is going to be several times lighter weight than ASIO which makes zero sense for file i/o vs socket i/o.
That said, whether or not a function throws exceptions is a design decision, nothing to do with run-time overhead. The reason, again, is that any exception handling overhead of calling a function can be easily eliminated, by inlining.
If the compiler can see all possible throw sites, and it is not called MSVC, then yes. I don't think people's issue is about what happens in practice under optimisation. They want *guarantees*. They want to see noexcept on every function because it's a *guarantee* that no matter what the programmer does, no unbounded execution times will occur. This is why games, audio and HFT shops ban the STL and disable RTTI and exceptions. It's about assurance, not reality in practice.
It is true that this will not make the function work faster in the case when it does throw, but at that time we're usually dealing with aborting an operation, it's an exceptional condition. I understand that this may be a problem in some weird cases but that's when I'd demand strong evidence rather than conspiracy theories and toy benchmark programs.
A lot of this debate isn't about empirical reality, if C++ programmers were managed by reality everyone would be using the STL with exceptions and RTTI turned on for years now. As I mentioned, it's about *assurance*: given a pool of average programmers, how can you (technical leads and management) be assured they will write on average low worst case latency C++? This is why I expect exceptions disabled C++ to remain around for a long time to come, and why AFIO v2 and Outcome will eventually support exceptions disabled. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/