Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-08-28 11:53:47

> > Anyway, a value that was consumed is a value that cannot be used again.
> > There are consuming operations that will consume the value. It's closely
> > related to the move idea, where the moved value is left in an
> unspecified
> > state. There are moving operations and there are consuming operations,
> but
> > consuming operations work on values other than rvalues too.
> >
> > Imagine a range that invalidates the original container. It *consumes*
> the
> > container.
> >
> > Does that explanation help?
> 
> Remember that Hartmut and Thomas are coming from a standards-ease
> perspective, and hence their disavowal of thinking in terms of
> anything not termed in standards-ease. You may not be aware Vinícius
> that Hartmut is a world leading expert in concurrency, and is one of
> the main minds behind the Concurrency TS.

Thanks for that, however I'm not behind the Concurrency TS. We have just implemented it very early on.

> I in the meantime don't really care much about design purity - if I
> did I would not write in C++. I do care about impure design causing
> users to write dangerous code which will fail in unexpected ways, and
> to that end consuming futures are usually superior. However in AFIO's
> case the thing being transported with non-consuming semantics is a
> shared_ptr, and both that and the handle it reference counts is
> thread safe. This, as far as I can tell, eliminates any chance for
> dangerous code being written by end users and is why I allowed that
> design choice and it does save significant additional typing to be
> written by end users.

Good design _always_ gives you everything you're striving for: safe and readable code, best possible performance, and users having 'fun' (as you put it) using the library. In addition, good design usually leads to 'beautiful', consistent, elegant, and generic code.

Bad design just creates the impression of all of this but will break in many subtle ways. Your long and winding argumentation why you have to use dirty tricks in order to achieve what you think you need is the best testimony for this. C++ allows for dirty tricks, but that a) does not mean you should use them, and b) too many 'experts' use those which is the reason why C++'s reputation as being too complex is still very common.

But all of this is just my personal (non-worldly-expertly) experience/opinion.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu