StephanTLavavej

MSVC’s STL (which I work on) is now open source, under the Apache+LLVM license: https://github.com/microsoft/STL . At this time, there are no plans to open source the MSVC compiler.

> Microsoft says that VS2019 runtimes are forward and back compatible with VS2015 and VS2017, however, it turns out that is not always the case, and we definitely encountered one of the incompatible scenarios.

The binary compatibility has documented limitations. As https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2... explains, "The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component." This allowed us to add VCRUNTIME140_1.dll as part of the "FrameHandler4" work that the compiler back-end team did. This decreases the size of exception handling info on x64 for compiled programs, sometimes significantly.

(I work on the Visual C++ team, on the STL. We regularly build Dolphin with our development toolset to prevent shipping compiler/library regressions, and to provide advance notice of source-breaking changes. I've had to report a couple of breaking changes to Dolphin and have been astounded at their prompt fixes - they are a wonderful team!)

Plexiglass: https://memory-alpha.fandom.com/wiki/Plexicorp

I am now thinking about filming an “Inside the STL” series to help people understand our implementation details.

That’s the symbol truncation warning. IIRC, the suppression is no longer necessary because the compiler removed the warning completely.

Metonymy has a purpose when it replaces a long, exactingly precise description with a short term that is equally recognizable. For example, “Wall Street” versus “US financial institutions, which may not necessarily be located in New York”.

An invalid use would be one that is not widely recognized. For example, referring to our library as MSVCP. That’s the name (minus version) of our DLL, but very few people recognize it as such.

Please see the Acknowledgments section of https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-s... .

I used to use “the STL” to refer to “the part of the C++ Standard Library strongly influenced by the design of the historical library”, excluding iostreams etc. Later, I decided this didn’t really achieve anything. It’s a Standard Library that’s full of Templates! There are other design philosophies in there, but they are increasingly unimportant. Having to say “C++ Standard Library” all the time, or trying to popularize a new acronym, are worse alternatives.

Yes, effective communication is valuable. I have been working on this library for over a decade and I find that the short, memorable acronym ultimately makes it easier to talk about the thing.

That said, we are primarily using the acronym for the repo URL and the directory structure; the readme makes it clear that this is “also known as” the STL.

The separately compiled parts of the C++ Standard Library have shipped in VS installations for many years (look for xrngdev.cpp in a subdirectory typically named crt/src, that should be distinctive enough). This was intended for debugging purposes, covered by the VS EULA as always. These parts weren’t standalone-buildable and we occasionally forgot to ship a file or two, but we always tried to make it all source-readable.

Now, being open source enables much more.

Wow, I didn’t know anyone followed my personal library (when I was still learning the language)! Glad it helped. Cool to meet a true fan :-)

Our commit history is stretched across multiple Microsoft-internal source control systems. In my career (2007+ in MSVC), that’s Source Depot, two databases of Team Foundation Server, and currently Git in Azure DevOps.

Unfortunately, we will not be making the history prior to the GitHub “Initial commit” public. It would be a huge amount of work, would bloat the git repo, and would be of little utility. (We occasionally have to perform programmer-archaeology, but rarely more than a year, and usually it’s only something that the developer who made the change can do due to personal memories.)

Consider this a fresh start. We will figure out a way to tag commits corresponding to shipped releases.

We really don’t like the preprocessor, but it is currently necessary for many things, especially supporting different architectures, compilers, and Standard version modes. We regularly purge our implementation of no-longer-necessary macros, even when it breaks (non-Standard) code, as we recently did with `_NOEXCEPT`, and we look forward to removing even more.

Please file an issue if you encounter macros that don’t appear to be necessary.

As barchar (my coworker on the STL team) mentioned, not only does Clang use MSVC’s STL on Windows, but also the support is from both Clang and Microsoft. We test MSVC’s STL with Clang as a first-class citizen, and have shipped features active for Clang before they were active for C1XX (MSVC’s compiler front-end), notably Class Template Argument Deduction.

Clang is a great compiler! We think it’s extra great with our STL. We added Clang/LLVM to the VS installer to make using it easier.

> There are still implementations of the original STL around separate from the std library, so keeping the distinction is probably still wise.

As far as I am aware, those libraries are defunct and unused (e.g. STLPort), so I disagree that there is an important distinction to preserve. The most widely used C++ Standard Library implementations by far are GCC’s libstdc++, Clang/LLVM’s libc++, and MSVC’s STL. Being bundled with compilers means that there is no reason to want an implementation of the historical ancestor library.

It’s what we’ve been calling our code for a long time (in VCBlog articles, etc.) and it’s a perfectly valid use of metonymy: https://en.wikipedia.org/wiki/Metonymy

Scott Meyers wrote a book called “Effective STL”, and there’s a somewhat-similar-interface library named https://github.com/electronicarts/EASTL - neither of these lead to confusion.

You’re welcome! My MinGW distro is due for an update, which I should hopefully have time for soon.

float to string is incredibly fast now - look at Ulf Adams’ Ryu and Ryu Printf algorithms, which I’ve used to implement C++17 <charconv> in Visual Studio 2019 (16.2 has everything implemented except general precision; the upcoming 16.4 release adds that).

I don’t know of truly fast algorithms for string to float, although I improved upon our CRT’s performance by 40%.

Splendor has a small bit of hidden info - when you blind reserve a card, you get to look at it, but it stays secret from other players. However, blind reserves are very rare, so you’re basically accurate.

constexpr isn't just a claim about today - it's a promise for the future. That is, the compiler can certainly notice that a function can be evaluated at compile time, and indeed optimizers will often perform enough inlining and constant propagation to boil down function calls to constant values in the binary. The constexpr keyword serves two purposes: it claims that the implementation is usable in constant expressions today (therefore allowing compilers to diagnose (i.e. emit compiler errors for) things that can't be done at compiletime, like I/O), and it promises that the implementation won't change in the future to be hostile to compile-time evaluation. This promise is important - otherwise, users could take a dependency on a function's current behavior (e.g. by using its result as an array bound, or as a template argument), and then they would be broken by implementation changes in the future that prohibited compile-time evaluation.

Glad to hear it!

Purr! Hiss!

Yes. Why say "unordered_map, unordered_multimap, unordered_set, unordered_multiset" or the boring "unordered_foo" when I can say "unordered_meow", and so forth?

Did you report the problem? It's too late for us to do anything about it in 15.3, but if something's still broken we can investigate it for 15.x.

We test our development builds against a large and growing number of open-source projects, but I don't think Ceres Solver is in our test matrix yet (I could be wrong).

As the post mentioned, we support almost all of the parts of the C11 Standard Library that are required by C++17. We also implemented a number of C99 Core Language features in previous releases. It is true that we don't support the entirety of the C11 Core Language, though. What missing features are you particularly interested in?

I've spent the last few months working on this release (alongside Billy, Casey, and Steve). When I started maintaining the STL in 2007, we released new features every couple of years - releasing every few months is much nicer (although I occasionally miss being able to break bincompat).

As I alluded to in this post, we're testing our STL with Clang (currently Clang/LLVM 4.0, soon to be 5.0 when I figure out how to get it to find my link.exe), and with libc++'s test suite. This has improved both our STL and Clang/libc++ upstream, and I'm grateful to their devs for working with us.

> Third, homelessness is on the rise nationwide.

That's incorrect according to "The 2016 Annual Homeless Assessment Report (AHAR) to Congress" at https://www.hudexchange.info/resources/documents/2016-AHAR-P... . Page 8 has a graph of all homeless people, which has been on a downward trend from 2007 to 2016.

"STL" is a perfectly valid way to refer to the C++ Standard Library through metonymy. Source: I am STL, an STL maintainer, with the sovereign right to name what I work on.

libstdc++ and libc++ are different libraries; this post is talking about libstdc++. They're like elephants and elephant seals.

Yes, that's C++14.

First, "class = enable_if_t<!is_reference<T>::value>" is just "class Dummy = enable_if_t<!is_reference<T>::value>" that doesn't bother to name Dummy. It's providing a default template argument for a function template (this is a C++11 feature; in C++03, only class templates could have this).

Next, "enable_if_t<!is_reference<T>::value>" is a C++14 library feature (enable_if_t is an alias template; the Core Language gained alias templates in C++11, the library gained these in C++14). It is a synonym for "typename enable_if<!is_reference<T>::value>::type", which is more verbose (and what one had to type in C++11).

"is_reference<T>::value" is a C++11 type trait, that is true when T is X& or X&&, and false otherwise. (It's implemented with partial specializations, and a "static const bool value = true;" data member - actually constexpr these days, but no difference there. This is type traits 101.)

enable_if is a library helper for SFINAE. (Not necessarily C++11 Expression SFINAE; here, just C++03 classic SFINAE is being used.) Basically, enable_if<true>::type is void. enable_if<false>::type doesn't exist. This works with the Core Language's SFINAE rules to make function templates vanish from the overload set (if you don't know what SFINAE is, look it up; it's a little complicated, but it exists for good reasons, and it goes back to C++98).

So, this is how one writes a function template that vanishes under certain criteria. This is often desirable compared to doing different things for different types (that can often be done with "tag dispatch") or emitting compiler errors for certain types (that's a static_assert).

There's no such thing as "pure" in Standard C++ yet, even the C++17 Working Paper.