It’s surprising to see it Apache licensed if that is the case. It seems Plauger is still selling it to other specialized compiler vendors.
It seems only a little while ago that I heard stories of a friend’s high school programming teacher, who received threats from Microsoft’s legal department for emailing them a patch
to fix a crash in Windows 95.
It's still the same Microsoft.
> This is the official repository for Microsoft's implementation of the C++ Standard Library (also known as the STL)
and appears to use the two terms interchangeably. Is this the C++ Standard Library or the STL?
But if you look at the repo you see the C headers like cmath, etc. that have nothing to do with the STL and are just part of the standard library.
The cmath header here just forwards to math.h and has no real content of its own.
So, what that read me says is correct, it is also called the STL. If you want to be precise you should probably only call it the std library though. There are still implementations of the original STL around separate from the std library, so keeping the distinction is probably still wise.
Also to complicate things, some people use the term STL to refer to the specific parts of the std library that are from the original STL. Those pieces are containers, algorithms, functions, and iterators I think.
tl;dr it's all a mess and people say the two meaning different things all the time.
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.
There's also the issue of credit. The STL is a work by Alexander Stepanov and Meng Lee. Conflating it with the C++ standard library of which it has become a part—or, worse, with a particular company's implementation thereof—has the distasteful flavor of plagiarism.
I really wish MS hadn't called the repo stl, it just adds to the confusion.
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.
> it’s a perfectly valid use of metonymy
and I'm not really sure what it means. I appreciate the wikipedia link and understand what metonymy is, but at the end of the day, metonymy is a figure of speech and formal technical writing discourages the use of extraneous figures of speech that don't serve any purpose, preferring clear technical language. If not this, then what does an invalid use of metonymy look like?
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.
So... not here? ("Standard library" and "STL" are about the same number of syllables).
I still think metonymy is a bit besides the point. The explanation "Using STL in place of the standard library is a perfectly valid use of metonymy, which is a type of rhetorical device, which is typically avoided in formal writing - therefore you should not do this" seems coherent to me. That is - being a "perfectly valid use of metonymy" is neither clearly an argument for not clearly an argument against the use of term.
I'm sorry, but effective communication is valuable and it is annoying that your employer continues to conflate the C++ standard library and the STL. Are we going to start referring to the standard library as "boost" a few years hence? That's basically the situation we've ended up in here.
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.
It's anecdotal but there certainly is a strong spirit of getting it right. I guess it's a characteristic of people working with it. In cpp details like that matter a lot.
I personally would feel more sympathy towards naming msvc implementation after your initials, then it could be even called STL library =D. Same effect with better motivation imho. Cheers.
Very cool release, but confusing naming. I'm sure it's longstanding practice at Microsoft, but maybe instead of saying "also known as the STL," it would be more clear to say, "which we also call the STL."
Anyway, I'm looking forward to poking around this code.
How are backreferences implemented here?
We regularly recommend customers use Boost if you need an API compatible version, or something like RE2 if you just need a fast regex engine.
The handling of repetition is more revealing, it doesn't appear to have "states" at all but rather is just the usual backtracking:
So the "NFA" is really an AST for the regex rather than an automaton based on Thompson's algorithm or similar.
PCRE's docs continue this confusion. For example, they expose a DFA API... But it's not actually a DFA!
One might say this is similar to how "regex" doesn't necessarily imply "regular," which is true. That's definitely a battle that has been lost long ago. But NFA and DFA are even more specific jargon terms, and the way in which they have been redefined by the Friedls of the world has led to exactly your confusion over and over again.
To be fair, the same thing happens with the Thompson NFA simulation. It's not too hard to add a little extra power to it in the form of memory in order to track capturing group locations. It becomes more powerful than an NFA with this addition, but retains its linear time bound. This is why I've normally seen this addition called the Pike VM. (At least, Russ Cox and I both use than name.)
For completeness, you can also use bounded backtracking to simulate an NFA. It keeps track of all states visited per input byte, so it uses a lot of extra memory, but maintains a linear time bound.
Also, backreferences stand a chance of turning an NFA into NIA. Turns out it's not possible to programmatically determine which backreference-containing regexes will halt or not.
--- LLVM Exceptions to the Apache 2.0 License ----
As an exception, if, as a result of your compiling your source code, portions
of this Software are embedded into an Object form of such source code, you
may redistribute such embedded portions in such Object form without complying
with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
In addition, if you combine or link compiled forms of this Software with
software that is licensed under the GPLv2 ("Combined Software") and if a
court of competent jurisdiction determines that the patent provision (Section
3), the indemnity provision (Section 9) or other Section of the License
conflicts with the conditions of the GPLv2, you may retroactively and
prospectively choose to deem waived or otherwise exclude such Section(s) of
the License, but only in their entirety and only with respect to the Combined
I am not a lawyer; this is my extremely limited understanding.
1. Normally the Apache license requires attribution, even in binary forms. We can't say "You said #include <string>, now you must staple this to all your binaries". libstdc++ has a similar exception to the GPL for the same reason: http://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
2. Keep GPL folks happy :)
Now, can anyone ELI5 the high-level goal of this exception? At a glance it looks like GPL2 folks are still not happy with the patent provisions of Apache 2.0 and this is added to appease them.
The first piece is standard for compilers, and essentially says "our compiler linking in bits of this code into your code doesn't count." It means the license matters if you're modifying the compiler and support libraries yourself, but not if you're merely using the compiler.
The second piece revolves around the concerns of mixing licenses: Apache 2 and *GPLv3 are happy in combination, but that's because of some explicit compatibility text in GPLv3; this extends the compatibility text to GPLv2.
> Non-goal: Porting to other platforms.
Last I heard, the maintainer of MinGW was one of those: never booted Windows, and tested only on Wine. (That was 20 years ago.) Someday Microsoft will be among their august number.
I'm not just talking about people who don't want to run Windows, I'm talking about things like CI infrastructure. Much easier to automate cross-building everything from one platform with one set of tools.
That said, apparently Microsoft's still is. For now.
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.
You can use libc++ nowadays. Works good enough for me.
It might be well for plain old Win32, but there is more than that across all Windows development scenarios.
Last time I had to resort to copying the files from an installation on a Windows machine (which is not very convenient).
Did Microsoft do this?
Google search turns up nothing.
Or were you using artistic license, equating announcing that they’re open-sourcing something with leasing physical billboard space?
webkit was a fork of khtml, so the webkit name started at apple but the actual underlying project not really.
Clang, on the other hand, was actually started at Apple.
The Clang project is part of the LLVM ecosystem, but is a major effort in its own right, so I think it is right to give credit where credit is due, in the same way e.g. the Rust compiler uses Rust as a backend, but credit for it doesn't to to the LLVM project.
He mentions this in some of his interviews.
I didn't write that they did? Though I can see where my wording would be misleading.
This is an extremely disingenuous statement. WebKit was forked from KHTML and everybody knows this. It "certainly" sounds like you're trying to rewrite history (and you make a similar assertion elsewhere in this thread)..
If “everyone” knows this, is it really disingenuous? In any case, I feel this is quite similar to saying Blink started at Google.
> It "certainly" sounds like you're trying to rewrite history (and you make a similar assertion elsewhere in this thread)..
I’m not. I have a very similar comment in response to a very similar correction elsewhere.
If you want to dig deeper, the mailing list archives are available for all, and I think given the contribution KHTML made to Webkit initially it is poor form to diminish its role.
"Blink started at Google". It's all context. As someone mentioned, it's technically correct but in the context of this discussion thread which is about open-source origins and contributions, saying Blink "started at Google" comes across as dishonest. Blink started at google with a fork of Webkit, which itself was not created in a vacuum at Apple.
You can read why here - https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
Which incidentally also supports Windows out of the box.
Apple also open sourced their kernel for iOS/MacOS
While Im not a fan of the corporation, its strategy and most of the policies, some dilligence is due here. They are known to release low level stuff.
In reality, I don't bother to do that and whenever I teach C++, I ignore MSVC and its STL. I'm willing to teach but Nooo, it's MS who prohibit me to do so.
Now I can't use that excuse anymore.
(Yes I know it can be found in the SDK, but having it as a repo on GitHub would just be so much more convenient.)
#pragma warning(disable : 4786)
 The "new MS" seems to delight a lot of people, but IMHO it's not all great; I'd much rather they not be "shedding" all this open-source stuff and kept selling software, if it meant they wouldn't stuff telemetry in everything they touch.
Just in case you/any other reader didn't know: That's just because they don't consider the ucrt compiler-version-specific anymore, it's distribution (binaries and source) moved into the windows SDK, E.g. Windows Kits\10\Source\10.0.17763.0\ucrt. The vcruntime is still with MSVC.
But this source never included the STL.
I'll concede I'm probably missing some obvious gotcha.
You mean things like vector, map, etc. ? The source for those is already in the header files.
Now, being open source enables much more.
An example would be if any performance enhancements can be ported to other C++ implementations.
Please file an issue if you encounter macros that don’t appear to be necessary.
CRT source really should also be also in an easy to find place instead of tucked away in the Windows SDK. But I've given up expecting any kind of actual developer consideration from the new Microsoft.
This also doesn't actually appear to have any commits corresponding to any released compiler versions- commit history only goes back a couple of weeks. I suspect they'll show up once an actual release has shipped out of this repository.
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.
Of course, but my point about the new Microsoft was in relation to UCRT source, which used to be part of the standard VC runtime library and distributed with the compiler.
This new release of the c++ stdlib is fine and I'd actually be fine with the entire C/C++ runtime (including UCRT) being on github. At least there'd be just one place to look for it.
(Edited after correction)
(re "We're working on a CMake build system... Until that's done, we're keeping our legacy build system around in the stl/msbuild subdirectory. (We're keeping those files in this repo, even though they're unusable outside of Microsoft, because they need to be updated whenever source files are added/renamed/deleted. ")
It's also fairly well documented: https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuil...
No, flipping, thanks.
Surely microsoft can, you know, pay you for the copyright if they want own it when they decide to merge your work? Or just take it on the same license. And as far as providing legal guarantees for microsoft? Yeah that's gonna be a no from any sane individual. Perhaps a big company like google might agree to those terms but also, perhaps not.
So no they don't want you to contribute, at all, or they'd do it right.
This looks quite disappointing. But as noted elsewhere you can read some source, or fork and refuse to contribute back I guess... But why?
No, you don't. You have to provide Microsoft (and anyone else, for that matter) a license to use your contribution per the CLA, but you still own your work. See section 5(a), https://opensource.microsoft.com/pdf/microsoft-contribution-....
All open-source licenses effectively require this; otherwise, by default, nobody would have a right to copy or use your contribution.
> give them a guarantee in case anyone sues microsoft over your work
I don't see an indemnification clause in the CLA. Which language are you referring to?
> (People sue without merit literally all the time and legal fees are bankruptcy material for any individual)
If they had even a shred of plausible belief, the estate of Elvis Presley could sue you tomorrow for defecating on a sofa at Graceland and potentially bankrupt you, even if you've never visited. What's your point?
"a. Copyright License. You grant Microsoft, and those who receive the Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the
Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute
the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third
The project has a license, just use it.
This is hardly a dangerous, radical criticism that is novel and needs to be fought on all fronts...
Copyright assignment has long been used as an argument of why not to contribute to FSF projects, and is arguably one of the reasons that Clang/LLVM were able to garner contributions from a much broader set of folks.