In fact, I'm working on Clang/C2 now, getting the STL and its tests to be compatible.
Dan Golick> Do the reumable functions support generators as in the working paper.
I asked Deon, who implemented await, and he said: "Not in the current implementation. We're still working on the design for it."
abir: Your #1 successfully compiles with our latest compiler build. (They've fixed several bugs in alias templates after the CTP snapshot was taken, most of which were found while we were implementing std::integer_sequence.)
I've filed your #2 as DevDiv#835786 in our internal database, and your #3 as DevDiv#835794.
I've gotten confirmation that constexpr arrays are also a CTP limitation, they just reused the warning for class literal types (which was confusing).
Thanks, I'll ask the compiler dev who wrote constexpr. That's emitting "warning C4425: 'const char (&)[N]' : 'constexpr' was ignored (class literal types are not yet supported)" which at the very least is an inaccurate warning.
You would say decltype(auto) for the return type, then return an lvalue (like ptr[idx]) for X&, or an xvalue (like move(ptr[idx])) for X&&.
Thanks for watching, everyone!
I've confirmed that the CTP is targeting C++11 constexpr (minus member functions), not C++14's extended rules which will require more infrastructure work in the compiler. They're working on it, but we can't promise anything for the next RTM.
Sebastian Redl> The non-await version of the code at the end is full of errors!
Yeah, that was just a quick sketch that Deon sent to me. I was all, "I'm filming in an hour, can you give me anything for await?"
I forgot to ask whether we had implemented C++11 or C++14 constexpr for the CTP, much less what our plans for the next RTM are. (Before filming my video, I dropped by all of the compiler devs' offices and interrogated them about their features, hence the detailed caveats I presented - I should have remembered about constexpr's spec changing but I didn't.) I'll find out.
NotFredSafe> Printing the 101 inside test2() is kind of redundant, because if zeroth didn't return a reference, the expression ++zeroth(v) would not even compile, right?
Yes for integers, no in general. Given int yinsh(), ++yinsh() is ill-formed (N3797 5.3.2 [expr.pre.incr]/1, "The operand shall be a modifiable lvalue.", and the expression yinsh() is a prvalue). However, given UDT zertz(), ++zertz() will be well-formed if the UDT overloads op++(). (For example, deque<T>::iterator.) This is because the preincrement is fancy syntax for a member function call, and non-const member functions can be called on temporaries (prvalues) unless specifically forbidden with ref-qualifiers (which didn't exist in C++98/03).
Mostly though, I considered it more fun to print something than to say "look, it compiles!".
Matt_PD> how viable is running VC 2012 Ultimate, VC 2013 Pro RTM, and VC Nov 2013 CTP (all three) alongside each other?
Running 2012 RTM/Update N and 2013 RTM side-by-side is supported and extensively tested. (As usual, there may be bugs in obscure corner cases.) The Nov 2013 CTP requires 2013 RTM, and *should* be unaffected by 2012's presence.
> -- any chance of reusing Boost Binaries built for MSVC 2013 in MSVC Nov 2013 CTP
Because this is compiler-only, you can probably get away with mixing-and-matching. I wouldn't recommend it, though.
> (if binary compatibility isn't expected, as I vaguely seem to recall, any experience with building Boost in MSVC Nov 2013 CTP? :>)
I believe the compiler front-end test team has been building Boost, but I don't know the details of their work.
Simon Buchan> You mentioned constexpr has restrictions in this release (better than it ICEing!) - are those defined anywhere yet?
It's not available on (non-static) member functions, including constructors. (I confirmed this with the compiler dev who implemented it.)
> 1) What do you mean by "(One optimization I currently don't do is to store bits in the distribution object
If you give me an mt19937 (32-bit input) and ask for [0, 32) (5-bit output), I run the engine once for each output, throwing away 27 bits every time. That is suboptimal.
> Am I right(not sure I understand you 100% correctly) that for evil values of output range this could happen almost 50% of the time
Yes. This happens when the output range is slightly greater than a power of 2, and around half of the input range. For example, mapping [0, 2^32) to [0, 2^31 + 5) is going to trigger a fair number of reruns.
With more math and more complexity I could reduce this (especially by accumulating bits). When I reimplemented uniform_int_distribution my focus was on correctness, not speed.
> So isnt it better to get 1 or 2 bits more
In practice, the input range is 2^32 or 2^64, so we're starting with plenty of bits for most outputs.