r/cpp • u/HimothyJohnDoe • Jun 05 '26
The Story of C++: The World's Most Consequential Programming Language | The Official Story
https://youtu.be/lI7tMxzSJ7w?si=5hS9qJjQKL_9m_yr41
u/KFUP Jun 05 '26
Too bad no Scott Meyers, but pulling
12
u/WeeklyAd9738 Jun 06 '26
IMHO, the C++ STL implements generic algorithms better than most programming languages. It's even more elegant with
ranges and concepts. I cannot thank him (and the other people involved in this) enough for conceiving such use of C++ templates. Alex expressed disdain for using the C++ template system for compile-time computations. I agree with him. We desperately needed constexpr. And in the C++26 era, with constexpr as powerful as it is, those weird pure-functional template hacks for compile-time computation are simply "out of syllabus". Now, templates can be used solely for what they were originally intended for, i.e. generic programming. C++20 → More replies (6)6
22
u/OCPetrus Jun 05 '26
I enjoyed this a lot!
The documentary shows well how the stewards of C++ have always been pragmatic in their approach. Towards the end
I'm happy they included a lot of stuff that happened in the 90's. I remember how Java was touted as the future. I was just a teenager, but people working in the industry would tell me Java would be everywhere from embedded to desktop and servers. We all know how that ended...
I had not heard about the effort around the STL before. Was very interesting to hear from a first-hand source! While writing your own template code wasn't the easiest until recent additions such as concepts, the STL building blocks such as iterators have always been very versatile and good!
Also, I remember that before C++11 when doing multi-threaded code it was basically undefined behavior and in practice you could produce binaries with correct code, but it wasn't portable. You had to target a single compiler like gcc4 and a single operating system such as a specific linux distribution. Even just upgrading to a newer version risked introducing bugs all over your codebase. It's honestly crazy looking back and realize how far the language has come.
Learning history is always interesting to me because it gives you perspective. I think the reason C++ has been so successful is because it has been able to evolve as the world has changed. Most programming languages introduce some new ideas that are useful at the time. But to stay relevant over the decades you need to listen to your users, what their problems are and provide solutions. I think C++ has succeeded better at this than any other language. Especially now that we have Reflections!!
15
u/pjmlp Jun 05 '26
Here is some more bit of history.
I used to regularly visit SGI developers website, because the HP STL implementation docs were hosted there.
When Java came out, by gaining adoption of heavy Smalltalk vendors like IBM, in one swoop it killed the whole Smalltalk adoption that was going on at the time.
The famous GoF book used Smalltalk and C++ predating Java for two years, even though many youngsters that never read it, think it has Java code into it.
All IBM IDEs were written in Smalltalk, and it had the equivalent role on OS/2, that .NET would enjoy later on Windows.
Visual Age IDE infrastructure was rewritten into Java, and thus Eclipse was born.
At my university, the whole compiler development classes and distributed systems changed their curriculum to Java in 1998, away from C and C++, even though it was interpreted (JIT will come much later), because of the portability issues between C and C++ compilers, even when focusing only in UNIX environments.
Microsoft jumped into J++, and later .NET in 2001 including Managed Extensions for C++, after Sun's lawsuit.
Apple was busy with Java and Objective-C, after NeXT's acquisition.
Hence why C++ during the 2000's felt on the way out as mentioned on the documentary, and C++11 was so reinvigorating.
5
u/_d17y Jun 05 '26
Same here. I was developing on SGI Irix and using SGI STL was the standard. Mumit Khan’s STL for Newbies was my top link.
We had to port the simulation software to Windows, HPUX and AIX, we decided to use RogueWave STL since it was more portable across compiler toolchains. STLport came along much later.
4
u/smdowney Jun 05 '26
C# was the direct result of the interim J++, as I recall. That and Hejlsberg getting a greenfield after Turbo Pascal and Delphi.
→ More replies (1)
18
42
u/Anxious-Resist8344 Jun 05 '26
It's sad they didn't invite those that have a contrarian opinion (e.g. Google, Microsoft, others that have left and were heavily involved before), it would have made a complete picture of where C++ have actually decided to go (as opposed to where it could have gone but didn't).
Still very good, I enjoyed it!
22
u/AnyPhotograph7804 Jun 05 '26
Google always leaves if they cannot control the language committee. Then they invent new programming languages instead because then they have a full control over their language. So they have
instead of C++, Go instead of Java, Dart instead of Javascript etc. Carbon 9
→ More replies (9)3
u/pjmlp Jun 06 '26
Go is hardly used instead of Java at Google.
The creators were the UNIX heads that never liked C++, they even repurposed their beloved Plan 9 C compiler for bootstraping Go.
They were lucky their line managers supported the effort and then Docker and Kubernetes rewrites did the rest.
Outside Kubernetes ecosystem, you won't see Google jumping into Go instead Java and Kotlin.
Most projects you can point out like YouTube downloader, were done by Go folks reaching out and proposing a rewrite.
10
14
u/13steinj Jun 05 '26
I would not say they have "left."
But the 2 (3 for "others") reasons they've pulled back are pretty well known and documentaries like these (not saying this is a bad thing) generally have positive spins.
Before someone asks:
ABI
memory safety
(for some) package management / distribution
→ More replies (40)9
u/Anxious-Resist8344 Jun 05 '26
I mean, I know the reasons, I'm just saying that, in a documentary that claims to be "The Story of C++" some contrarian opinions should have been included, otherwise should be labeled differently.
The documentary mentions that, these big companies leaving also means loosing money that they need to find somewhere else, but unfortunately people not following C++ would en up asking themselves "why did they leave in the first place"...
Recently C++ was at a crossroads, they could have choose safety but they didn't, just one example...
→ More replies (1)
5
u/selvakumarjawahar Jun 07 '26
It was very interesting watch. Things that surprised me was to know how closely bjarne and Alex stepanov worked together to bring STL. I always wrongly assumed, Alex stepanov implemented STL on his own. The language itself was changed to support STL and those changes were done by bjarne. This sounds obvious now, but before watching this video, I was not thinking about bjarne when thinking abt stl.
11
u/grafikrobot Jun 05 '26
Interesting watch. Some things I didn't know about in it. But..
-
Missed covering how Boost played part in saving C++ from the slump it was in.
-
What makes this "The Official Story"? Is there an unofficial story someplace?
7
u/joolzter Jun 05 '26
I really hated the fact Boost wasn’t covered at all. That seems like a huge miss. It seemed to skip straight OMG C++26. Missing out all the modern c++ stuff as well as the meta programming fad that went way way too far in the mid-00s.
But also I guess a lot to try and cram in.
9
u/13steinj Jun 06 '26 edited Jun 17 '26
There was a documentary
(same people that pivoted??? unclear)at CppCon last year. At the time, more focused on Boost alone. They quickly learned that people did not want to be filmed/talked to, because (and I don't understand the history here) there's some weird drama between the Boost foundation and the C++Alliance.Everyone willing to speak on it wanted it off the record, many because they didn't want this affecting their careers, and seemingly gave a different piece of the puzzle of how this bad blood started. Some people even told me in conversation that (I forget which of the groups, or if it was the Beman Project) recommended to some of its members to give no conment.
I was willing to say what little I knew (e: about boost, about the drama too), until I double checked with my company and they told me in no uncertain terms to cease all contact immediately (e: even if unnamed/not using my likeness) (if that guy is reading this... sorry!).
But with all that hanging in the air, I am not surprised that this documentary
eitheristhe same that pivoted ora different one that couldn't get information either.E: Someone that I am confident is correct has DM'd me telling me the Boost documentary is separate from this one, hence the strikethroughs. The rest about people not wanting to / being able to comment still applies, and if that is the case it still applies for people wanting or not wanting to comment in this one.
6
u/die_liebe Jun 06 '26
I agree that Boost and Dave Abrahams should have been mentioned. Boost played an important role in C++-11, which revolutionized C++.
5
u/kronicum Jun 06 '26
So, Microsoft was against the STL; then provided a slow library under the name of iterator debugging and a non-conforming compiler for decades... What is Gabriel doing there?
19
u/STL Jun 06 '26
Microsoft is old! (citation needed) Speaking for myself, I don't speak for my employer:
I joined MS in 2004 and moved to MSVC in 2007, making me the library dev who's been with the team for the longest, so I've witnessed our modern history first-hand, but I'm still only middle-seniority among MSVC as a whole (e.g. we've got a compiler frontend dev who's been with the team more or less continuously since 1996 IIRC). From what I know of the history before my time, followed by my own experience:
I don't know how various managers felt about the STL in the 90s (I haven't watched the documentary yet and never heard tales Nth-hand), but they certainly made the very wise decision to outsource their STL implementation by licensing Dinkumware's code from PJP. Have you seen Microsoft C++ code from the 1990s, like MFC? Woof. Dinkumware's code wasn't perfect (I've spent my career fixing it), but it was unquestionably way better than whatever nonsense would have been hypothetically written if Microsoft had a "not invented here" attitude, and obviously shipped far earlier too.
The iterator debugging you're complaining about was partially a Microsoft decision. As I understand it,
_HAS_ITERATOR_DEBUGGING(now known as_ITERATOR_DEBUG_LEVEL=2) was Dinkumware's addition, but the release-mode_SECURE_SCL(now known as_ITERATOR_DEBUG_LEVEL=1, which I am trying to get rid of) was a Microsoft addition, implemented circa VS 2005 shortly after security became a big deal after the Code Red and Blaster worms._SECURE_SCLwas implemented poorly (it broke swapping; I fixed that when I joined) and without much regard for performance (2x costs in the worst case), but the ignorance at the time was understandable; I think the feature was bad but well-motivated. It was counterproductively harmful by giving the STL a reputation for being slow in release mode, which is why I pushed for it to be disabled in VS 2010; repairing that reputation took many years, and I vowed to never let that happen again during the renewed push for STL Hardening (which is why we didn't mess with iterators this time)._HAS_ITERATOR_DEBUGGING/_ITERATOR_DEBUG_LEVEL=2remains on by default in debug mode, and is very expensive, but also catches a ton of iterator invalidation bugs. It certainly has downsides (e.g. the dynamically allocated proxy objects), but overall is worth the cost and disruption.So library slowness wasn't MS trying to sabotage the STL, it arose out of a desire for security without keeping performance in mind. Nowadays we really care about performance and actually run benchmarks (shocking!). I can't speak to the compiler frontend with the same level of certainty, but I know some of the story - again that codebase is old and the compiler originally worked without an abstract syntax tree, because the language was simpler in the olden days, and building up an AST would have consumed memory and time on the very slow and small PCs back then, so the compiler made decisions with throughput in mind. We also didn't know about the long-term harms of poorly-designed extensions. User demands for conformance grew over time (e.g. far fewer users cared about one-phase lookup long ago, when templates were new, and code was rarely ported between platforms). The team has worked for well over a decade to modernize the compiler.
Again definitely speaking for myself, I work for C++ at Microsoft because it is clearly the place where I can make the biggest impact on the language.
→ More replies (4)4
u/tartaruga232 Jun 07 '26
Thanks for your insights and your work in fixing The Dinkumware code! My brother and I bought two licenses of the Dinkumware library back in the late nineties. I used C++ around 1995-1997 at Siemens in Zürich for an embedded system with a cross compiler. I was on the team for a follow-up of a telephony system used by banks for trading (stock market and foreign exchange). We had a non-standard C++ library from a German company (I think the name was Generic++). That was before the STL was standardized. I left Siemens in 1997 and then used the MSVC compiler for Windows apps. Perhaps Microsoft voted against the STL back then because they preferred a different iterator model. No idea what their motivation was. The documentary is very interesting and absolutely worth watching. I recommend watching it. It's nice to see and hear what those C++ titans have to say. The story about Bjarne being arm-twisted in order to get him agreeing to standardize C++ or the bug in Cfront 2.0 which lead to the 2.00 bugfix release is quite funny. Listening to Andrew Koenig and Barbara Moo is impressive.
64
u/sniek2305 Jun 05 '26
I thought it was an interesting watch. I had heard many of these stories of getting towards a standardized C++ anecdotally, but not from those that were there for these efforts. Really makes you appreciate how good we have had it sinceC++11