On 05/26/2015 12:20 PM, Niall Douglas wrote:
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?
I believe it is an accident. While the compiler is required to fold a constexpr expression in a constexpr context (like an array dimension or non-type template argument), it isn't required to do so in non-constexpr contexts, and won't do so if optimization is not enabled or if it makes a bad inlining decision (say, because the function was too large). The optimization machinery for folding constants is actually a superset of constexpr, and as a result you will sometimes get a constexpr expression not optimized, and sometimes a non-constexpr expression will be folded to nothing.
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.
I am also waiting for resumables (and concepts, and modules, and ranges...) with bated breath.