C++ Team Blog

> I don't think that's true or nothing compiled using MSVC could ever be open source. For example: Rust

It is true. Rust does not require MSVC in order to compile. Also, linking to proprietary code, and compiling code using a proprietary binary, are completely different things. A distribution of Rust which contained a proprietary library would not be open source, but that's entirely allowed, because Rust's license isn't viral.

As it happens, the linkable portion of MSVC is Apache 2.0:

https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-stl/#:~:text=A%3A%20MSVC's%20STL%20is%20distributed,share%20code%20between%20our%20libraries.

This is so that open-source software which requires MSVC framework remains open source.

Please see this classic thread for more details:

https://gitlab.com/gnu-clisp/clisp/-/blob/master/doc/Why-CLISP-is-under-GPL

I'm not opposed to proprietary software, and as long as people clearly understand what they're getting into, they should make their own choices about using Lady Diedre. But the FAQ is dishonest, and I have a problem with that.

> You are not obligated to accept any new terms or amendments. In such a case, this Agreement will continue to govern your use of the Work you have already accessed under the original terms. However, if you do not accept the new terms or amendments, you will not be permitted to use any new versions, updates, upgrades, or modifications to the Work.

Great. Be sure to pin the cargo version of your…

The license was explicitly chosen to enable code sharing with LLVM's libc++ (https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-stl/).

The MSVC STL's quality is good enough for thousands of pieces of Windows software (including Windows itself & Microsoft's software such as Office) to depend and rely on. It delivers excellent performance for a broad range of use cases. It is actively developed in the open, delivering cutting-edge (C++23 & C++26) features, accepting Pull Requests and wonderfully documented on GitHub. It can be consumed using MSVC and LLVM clang-cl (which the MSVC STL maintainers test with CI infrastructure). The maintainers are actively working on "hardening" features to enable more secure C++ (https://github.com/microsoft/STL/wiki/STL-Hardening).

Unless you specify what "best" or "a library's quality" means to you, MSVC STL is excellent and because of that, the default choice on & for Windows.

Google chooses to only support libc++ for Chrome/Chromium (https://chromium.googlesource.com/chromium/src/+/main/docs/toolchain_support.md). libc++ is not a Google-owned project.

Not sure why this got downvoted? Anyone to comment? I use C++ daily on my job, and I'm very happy with its developments - especially C++11, C++14, C++17 and what's coming in C++20 - but statically linking problems are real, and pain to solve (long term). We do mostly MSVC, where some teams are still in VS2017, others VS2019 - and while they are compatible - the compatibility works only if your final app is compiled with the latest compiler from each version, which puts our team (doing mostly libraries, and providing precompiled ones) that we should use the lowest version, but then our CI infrastructure might use even earlier.

With "C" there is less to care there, as most is set in stone (unless you use some really compiler vendor specific extensions, that appear during link time).

Just an example - https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/ - this is great improvement, but also means that if you've compiled your lib with VS2019, and it throws an exception under application that uses VS017 - it'll not work.

Either of your mentioned options for implementing template parsing were used by implementations when C++ was conceived (but before it became an ISO standard). Your "token string" approach is the route that Microsoft took with MSVC, whereas other compilers went with what later became standardized as "two phase lookup".

In short: Token stream alone is not enough. You need to decide whether T::A * b; is a pointer declaration or a multiplication immediately when you parse the template. If A is a dependent name (i.e. if T is a template parameter), it is assumed to be a variable (if that's not correct, the programmer must use typename or template).

MSVC has only recently completed their implementation of two-phase lookup, some twenty years after it was defined as the correct option in the ISO C++ standard. They have an excellent writeup here: https://devblogs.microsoft.com/cppblog/two-phase-name-lookup-support-comes-to-msvc/

Obviously it would be of great historic interest, but as a living software, just no. Go read this: https://blogs.windows.com/msedgedev/2017/04/19/modernizing-dom-tree-microsoft-edge/

IE implemented DOM without using tree. No, really. Up to 2017. After reading the article, all my questions why IE was so buggy evaporated and replaced by how could IE work at all.

MSVC up to 2015 also didn't create AST. Unbelievable, I know. The question is not why MSVC's C++ support was so buggy; the real question is how could MSVC implement C++ at all. https://devblogs.microsoft.com/cppblog/rejuvenating-the-microsoft-cc-compiler/

After learning about IE and MSVC, I gained respect for Microsoft developers and disdain for Microsoft. Tightrope walking is amazing display of skill. Letting your employees to commute by tightrope walking for years is amazing display of stupidity.

They officially saw no need for C support going forward.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99

Note,

"If you really need either of the following.....then we recommend that you consider using a different compiler such as Intel or gcc (short-term) and/or pressure your standards committee representatives to have ISO C++ include more of the C standard (longer-term)."

Which is kind of why nowadays clang is part of Visual Studio as well.

However, after Satya got into the whole Microsoft <3 FOSS, this changed a bit,

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc

There are a few blogs after that, so at least up to C17 minus the optional parts from C11, the support is there.

It remains to be seen if anything C23 or later will ever come into MSVC, and then again, clang is part of VS installer.