On 26 May 2015 at 2:36, Peter Dimov wrote:
In my implementation, if you never call promise.get_future() you never get synchronisation.
That's an interesting use case. When does it occur?
make_ready_future().
The constexpr folding has the compiler elide all that.
I suspect that what you call "constexpr folding" has nothing to do with constexpr, it's just inlining and ordinary non-constexpr optimization. KAI C++ was famous for doing such folding miracles decades ago.
You're right it's not in the standard. Well, actually it is, but indirectly. Let me explain. If you read what is allowed for constexpr at http://en.cppreference.com/w/cpp/language/constexpr, and then write logic which provides outcome paths which do nothing not constexpr, then the compiler will completely elide code entirely at compile time when those paths are followed. If you examine my code closely, you'll see I always predicate the construction of anything with a non-trivial destructor (e.g. exception_ptr) because non-trivial destructors appear to force code output in current compiler technology, though it may also be the atomic writes that exception_ptr does. This probably is not by accident. The machinery inside the compiler to implement constexpr is probably reused for optimisation, or rather, vice versa. Maybe a compiler vendor might chime in here to tell us?
Also if you call promise.set_value() before promise.get_future(), you never get synchronisation as futures are single shot.
Another interesting case for which I've trouble imagining a practical use. :-)
Its main benefit for me is as a unit test smoke test. However resumable functions, as currently proposed, should hugely benefit from this pattern. I've emailed Gor about it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/