StephanTLavavej

I don't know anything about iOS/Android targeting, but I've asked people who do to comment. I do not believe that pthreads will be available for Win32 but I could be wrong.

<thr/xthreads.h> is internal and unsupported; please don't use it.

In fact, VS's STL has to defend itself against those macros. Since the user might have already included windows.h without NOMINMAX, what we do is parenthesize all mentions of min/max, which inhibits preprocessor expansion of function-like macros. Look at our declarations of std::min()/etc.

I can answer questions either here or on VCBlog.

EDIT: Specifically, questions about the C++ Core Language and Standard Library, which is what I work on all day; questions about other topics are welcome but other MS people will have to answer them, since I am mostly clueless about other areas.

I'll be publishing an updated feature table soon.

The C11 Standard Library has not been incorporated into any C++ Standard (not even the C++17 Working Paper as of right now), so we have not attempted to support it. On the other hand, our C++11 <atomic> implementation has been significantly improved in VC 2015.

Ha, that's cool to hear!

Specifically, in 2015 our C99 Standard Library implementation is complete, except for tgmath.h (irrelevant in C++) and the CX_LIMITED_RANGE/FP_CONTRACT pragma macros.

Uh, Armstrong and Aldrin walked on the moon, with Collins in orbit.

What's a left-right rule? Arrow binds tighter than deref, just like multiply binds tighter than plus. That's * (x->a->c)=5, just like how a * b * c + d * e * f works. C and C++ have some confusing precedence (famously, bitwise), but this is not one of them.

In C++11, auto just says, "make the type of this thing the same(ish) as the type of its initializer". There is no potential for code bloat, even in theory. In C++14, auto can be used for generic lambdas, but even those are almost always called with a single set of argument types, so again no code bloat even in theory.

(Template code bloat itself is nearly mythical. I've seen exactly one occurrence of it causing a problem, in 8 years of Standard Library maintenance.)

My erase_if proposal was accepted for the Library Fundamentals v2 Technical Specification and is therefore likely to get into C++17.

std::random_device is part of C++11, and VC's implementation guarantees that it's crypto-secure.

It's an antipattern. Consider the following scenario: a function says "something = move(passed_by_value);". When called with an lvalue, this assumes that copy construction followed by move assignment is as efficient as copy assignment would be (which is what you get when you overload for const X& and X&&, or perfectly forward). This is untrue for vector/string-like things. When you copy construct a vector/string, it must allocate space for N elements, then copy then. Move assignment just transfers ownership, that part is fast. But consider copy assignment. If the destination has sufficient capacity, NO allocation will be performed - instead, the existing elements will be destroyed and the sufficiently-large buffer reused to hold the new elements.

Therefore, "want speed? pass by value" can result in worse performance. Overloading for copy/move is near-optimal and perfect forwarding is optimal - this is what the STL does (push_back is copy/move overloaded, emplace_back perfectly forwards).

> Why doesn't <istream> include <iterator> instead?

Users must be able to include <iterator> by itself, and get istream_iterator.

We do break things up into internal headers, we just haven't done that as much as possible. Come to think of it, equal() is defined in one of our central headers, so we should probably take advantage of that in <array>.

From our (STL maintainer) perspective, <array> includes <algorithm> because it needs equal(), <iterator> because it needs reverse_iterator, and <tuple> because it needs to provide get(). Minimal!

But yeah, it drags in a whole tree of headers. Minimizing this is possible, and we've taken steps to do so in the past, but it's a lot of work for possibly minimal benefit - user translation units tend to drag in many STL headers, especially if they're using precompiled headers like they should. We think our time is better spent fixing correctness bugs and implementing features.

The init list bug has been fixed for 2015 RTM. Also, I fixed the clocks back in 2015 CTP1 (alpha 1). Sorry about that bug, we just didn't get a chance to fix it in 2013 - in that release we were insanely busy converting the whole STL over to real variadic templates.

By my count, none of VC 2015 RTM's C++17 features will have been proposed by MS. N3922 auto and N4086 trigraphs were proposed by Googlers. Same for another Core feature that might be checked in. In the Library, I just checked in void_t, invoke(), and trivially copyable reference_wrapper, none of which I proposed (or anyone else at MS). I did propose auto_ptr/etc.'s removal which was voted into C++17, but it's too late for me to remove that stuff from 2015 RTM.

Correction: shared_ptr wasn't in C++98/03. It was originally developed in Boost, then added to TR1 (in 2005), and finally incorporated into C++11.

One of the major differences between shared_ptr and CComPtr is that shared_ptr is non-intrusive - it can manage anything, even things like ints that don't know anything about strong/weak refcounts.

Sorry, wasn't checking my HN comments frequently (unlike Reddit there's no little red icon).

"meow" is a traditional string literal, whose type is const char [5] (array of 5 const chars). When you say "auto", you get the same deduction as when you pass something to a template foo(T t) taking by value. This triggers "decay", where arrays decay to pointers. Hence auto (and T) is const char *.

"meow"s is a user-defined literal (the Standard Library is a user as far as the compiler is concerned), for which you must include <string> and say "using namespace std::string_literals;" or something equivalent. The specification for UDLs says that this calls operator""s() which returns a std::string by value.

Yep, I'm the video guy. Glad you like them!

That's incorrect. I majored in CS at Caltech, but I think I can explain this properly. It doesn't have anything to do with orbiting or angular momentum.

Imagine that only the Earth and the International Space Station exist. The ISS is doomed because it has stopped orbiting, and is falling straight down. Inside the ISS, an astronaut has placed 5 marbles in the shape of a plus sign (center, left/right/up/down). For convenience, the "center" marble is also at the center of mass of the whole ISS. There's no air or anything to mess up the results. What happens to the marbles?

Look at the problem from the frame of the Earth. The Earth is exerting a certain force on the center marble, call it F. The "down" marble is slightly closer to the Earth, so it experiences a greater force, F + Something. The "up" marble is slightly further from the Earth, so it experiences a lesser force, F - Blah. The "left" and "right" marbles experience forces very very close to F (slightly less, if they're in a straight line, but much closer to F than F - Blah). However, those forces are directed towards the center of the Earth, so those vectors have small components directed towards the "center" marble.

Now that we've figured out the forces, look at the problem from the frame of the marbles. We're in free fall, so the "center" marble floats motionless. The "down" marble is going to float further away from the center marble (F + Something pulls "down" harder), and the "up" marble will also float further away from the center marble (F - Blah pulls "up" less than everything else). The "left" and "right" marbles float towards the center.

Using only Newton's laws, this reveals that gravity's behavior over a volume has a stretching effect in the up-down direction, and a squeezing effect in the left-right direction. GR confirms this. This effect is the tidal force.

When applied to the Earth and the Moon, this explains the two bulges. The bulge closer to the Moon is due to F + Something, because that water is being pulled stronger. The bulge away from the Moon is due to F - Blah, because that water is being pulled less than everything else.

C++14's "meow"s is syntactic sugar for string("meow"), with identical efficiency.

C++ did that first. C++98 and C99 implicitly "return 0;" when falling off the end of main(). It was C89 that required "return 0;" here.

You need an atomic load, followed by an ordinary comparison. On x86 and x64, this is cheap (properly-aligned loads and stores are already atomic, and the architectures do very little reordering that has to be prevented). On ARM it's more expensive.

You're probably thinking of things like atomic increments, which are one to two orders of magnitude more expensive than an ordinary increment.

This has been fixed in C++11. In fact, there are several alternatives. <atomic> provides sequential consistency by default, preventing the seemingly-bizarre operation reorderings described here. std::call_once() does exactly what it says: it allows multiple threads to call something exactly once (with robust behavior in the face of exceptions). And the magic statics feature in the Core Language makes the construction and destruction of function-local statics thread-safe (protecting actual usage is up to you).

> VS14 RTM (which, as a reminder, is scheduled for 2015)

Actually, the compiler can distinguish between sort(Range, Pred) and sort(Iter, Iter). This is a C++98 feature, partial ordering of function templates. Basically, if you call sort(range, pred) then the sort(Iter, Iter) overload will be ignored (since template argument deduction can't succeed - Iter can't be two different types). If you call sort(iter1, iter2) then both overloads are viable, but sort(Iter, Iter) is preferred - partial ordering determines that it matches a strictly smaller infinite universe of types.

This is also why C++14's dual-range algorithms didn't lead to ambiguities: equal(InIt1, InIt1, InIt2, Pred) versus equal(InIt1, InIt1, InIt2, InIt2) has the same structure.

(Obviously if you have a type that is both a range and a predicate, then it's ambiguous.)

The talks were professionally recorded (and will be available in like a month). Thanks for the reminder about notes - I don't need them myself, but I didn't consider that people would want to read them in the slides.

> The title matched the contents (unlike yours it seems to me)

How do you think my title differs from the contents? As far as I can tell, it is completely accurate.

Yeah, the presentation covered those parts (motivation, and putting the pieces together). C++14 rejects the bad code by providing a deleted overload for const string&&, as covered in the following slides.

My slides are already at the upper limit for information density - I don't think I could cram even more into them.