StephanTLavavej

That guidance isn't correct in the C++11 New World Order. For maximum performance, you must think about move semantics. Simply saying const X& everywhere will inhibit move semantics (can't move from const, can't move from lvalues, especially can't move from lvalue-ref-to-const).

For example, suppose you're writing a FancyAppend() function, that will return "LhsString, RhsString". Following your guidance, the signature would be "string FancyAppend(const string&, const string&)". While that definitely avoids copying the inputs, it is not optimal. Providing additional overloads for string&& parameters can be more efficient (if at least one input is a modifiable rvalue, it can be appended to in-place, which can avoid additional memory allocation if it happens to have sufficient capacity; for repeated appends, this can avoid quadratic copying of elements). Indeed, this is what string's operator+() does.

Note that working with rvalue references does require more understanding. For example, the signature "string&& BadAppend(string&&, const string&)" is a severe error (one that the Standardization Committee made early on, and corrected before shipping).

Part of it was surely programmer confusion, but old compilers in the C++98 days were also worse about implementing the RVO/NRVO. For example, MSVC didn't implement the NRVO until 2005.

It's a little more subtle than that. "val" is definitely an lvalue. However, when returning a local variable like this, C++11 has a rule: "if the NRVO activates, there are no copies/moves. Otherwise, see if you can treat val as an rvalue - if so, you get a move. That almost always works, but if it doesn't, fall back to treating it as an lvalue so it compiles with a copy like it used to."

This is the one time in the language that lvalues are automatically moved from, and it's because the language/compiler knows that returning from a function will destroy all local variables, so it's safe to move from them.

Copy elision, including the RVO and NRVO, actually has to be blessed by the language (there is a paragraph in the C++ Standard dedicated to it). That's because copy elision skips calls to copy constructors and destructors, which are "observable" (they can have side effects, including printing stuff to the console, etc.). The general "As If Rule" permission to optimize "unobservable" things away doesn't apply here, so special permission to drop the calls is required. This is true going back to C++98 (C++17 strengthened things with guaranteed copy elision).

Actually, it's not even close. 10,000 attempts to guess a 4-digit number are certain to succeed. 100 attempts to guess 100 4-digit numbers have a good chance of resulting in no hits. For each 4-digit number, you produce 100 different guesses (with no repeated guesses for that number, because that would be silly). There's a 100/10,000 chance of a hit, and 9,900/10,000 chance of a miss. The chance of missing on all 100 4-digit numbers is (9,900/10,000)^100 = 0.366 = 36.6%. That's substantial!

Guessing 100 numbers, there's a chance to produce 2 or more hits, of course.

MSVC provides that feedback. See https://msdn.microsoft.com/en-us/library/jj658585.aspx - the compiler option you want is /Qvec-report:2 which "Outputs an informational message for loops that are vectorized and for loops that are not vectorized, together with a reason code."

Hmm, as long as you don't always use the big cube as the baseline, that works.

> From this it seems enough to only test combinations where two edges align.

That can't be correct in general. Imagine a 9x9x9 cube, and nine 3x3x1 squares. This can fit into a 9x9x10 box, with the squares all on one side of the big cube. However, four of the squares will share only one edge with the cube, and one of the squares will share no edges with the cube.

Yeah, it makes migrating a codebase with third-party libraries built with older toolsets easier. Note that you'll need to build with VS 2017 if you want header-only improvements like the vector overhaul, and you'll need to update to 2017's VCRedist if you want DLL improvements (e.g. if you're still on 2015 RTM's msvcp DLL, you don't have the iostreams correctness/performance fix that shipped in 2015 Update 2; DLL improvements are uncommon but they do happen).

In MSVC's STL we're making major changes, adding lots of features in pursuit of C++17 conformance. Among other things, we've added several new headers between VS 2015 Update 3 and VS 2017 RC (<string_view>, <optional>, <variant>, <any>), and we've totally overhauled std::vector's implementation for correctness and performance.

MSVC STL dev here. We're doing something different this time around. VS 2015 RTM and Update 1/2/3 were binary-compatible (as usual) while adding lots of features to the compiler and STL (unusual). VS 2017 RTM and its Updates will continue to be binary-compatible while adding features, meaning that our DLLs are still vcruntime140.dll, msvcp140.dll, etc. The versions are admittedly a mess, so here's the magic decoder ring:

VS 2015: IDE version 14, DLL version 140, toolset version 140, compiler version 19.0 (the C++ compiler is older than the Visual part of Visual C++). VS 2017: IDE version 15, DLL version 140 (same!), toolset version 141, compiler version 19.1

We still recommend that you build everything with VS 2017 consistently, as this will give you the most performance and correctness. However, you can mix in object files, static libraries, and DLLs compiled with previous versions all the way back to 2015 RTM, and things will continue to work (although you won't necessarily activate fixes in the newer version).

For more info, read the comments on https://blogs.msdn.microsoft.com/vcblog/2016/08/24/c1417-fea... where I mentioned WCFB02.

As of MSVC 2015 Update 3, the support for C++11 is nearly complete. The missing pieces are that Expression SFINAE is partially supported (what's there is good enough for the STL and Boost, with certain workarounds that you must be aware of), and C99 preprocessor support is full of bugs. Aside from that, all features are present and generally usable. (Some are buggier than others; e.g. we're overhauling multithreading library support for the next major version of the libraries.)

Sugar contains carbon. Perhaps you're thinking of gluten.

As an STL maintainer, I can say that using "STL" to refer to "the C++ Standard Library" is a perfectly valid use of metonymy.

The first comment, from fourbadcats, is apparently from a customer of MS (I don't know who they are), referring to their customers in turn. The second from spongo2 is VC's dev manager, my double boss. (I know very little about this topic as the STL's senior developer; this stuff is in the vcruntime layer below the STL.)

Fun fact: the compiler's version (19) is larger than the IDE's version (14) because the compiler predated the addition of "Visual" to the branding. (And the IDE skipped 13, while the compiler didn't.)

Star Trek memorably listed LT CDR NFN/NMI DATA, see the screenshot at http://memory-alpha.wikia.com/wiki/Data (third from the top, on the right).

Actually, my proposal to remove auto_ptr etc. from C++17 was accepted: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n419...

R. Daneel Olivaw was Chetter Hummin (and Eto Demerzel).

In C++11, std::sort() is forbidden from being just a quicksort, as it's required to have worst-case O(N log N) complexity.

Minor correction: qsort() is CRT, std::sort() is STL.

I updated MSVC's STL to handle these things, and it wasn't nearly as obnoxious as I feared. Almost all of the complexity was centralized.

Orphan Black is great, but it isn't produced by Amazon.

That's incorrect - the Ranges TS was just started, and certainly hasn't been published yet (not even as a PDTS). Filesystem was the first published TS.

> Atomics in signal handlers - N2547 - its listed as missing here (at msdn), but listed as done here at vc blog

That was me being cautious, see http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17... - "I previously listed "Atomics in signal handlers" as No, because despite maintaining <atomic>'s implementation, I didn't know anything about signal handlers. James McNellis, our CRT maintainer, looked into this and determined that it has always worked, going back to our original implementation of <atomic> in 2012."

I don't believe that any "destructive move" proposals have advanced out of Evolution and into Core. The issue is whether moved-from objects should be in a weird twilight state ("valid but unspecified"), which is the status quo, or whether moving from an object should straight-up destroy it. The question is... controversial.

C1XX uses new features fairly aggressively. For example, it uses lambdas, auto, range-for, etc.

Yes, both MSVC's front-end C1XX and back-end C2 (aka UTC) are written in C++. Even our CRT is mostly C++ now.

You'll want to read these changelogs for the CRT and the STL: http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-featur... , http://blogs.msdn.com/b/vcblog/archive/2014/06/06/c-14-stl-f... , and http://blogs.msdn.com/b/vcblog/archive/2015/07/14/stl-fixes-... .

I believe we're hoping that Clang/C2 will satisfy those who want to build C99 TUs on Windows. Personally, I have absolutely no interest in C99 (I wasted a year and a half of my life learning C before C++).