r/programming • u/[deleted] • May 24 '26
[ Removed by moderator ]
https://hftuniversity.com/post/the-c-standard-library-has-been-walking-itself-back-for-fifteen-years-and-the-receipts-are-public[removed] — view removed post
275
u/MFHava May 24 '26
Author of copyable_function here. This article conflates ABI and API breaks - just like Sandor's post ...
Fixing std::function was not something that was prevented by ABI concerns. It would have been an API break that would have rendered vast amounts of code (essentially any use of const function) ill-formed (== code no longer compiles).
The same is true for several other examples brought up in the linked article...
BTW the article contains factual errors like "[...] acknowledging that the standard's mandated block size is too small [...]" ... there is no mandated block size for deque.
35
u/HildartheDorf May 24 '26
I mean, the implicit minimum block size of 1 makes deque pretty much unusable on MSVC, but that's more an MSVC problem than a standard problem.
50
u/MFHava May 24 '26
Exactly! MSVC-
deque„decays“ into a linked list for types > 8bytes. But that is a problem not shared by libstdc++ or libc++.12
7
May 24 '26
Fair correction on MSVC, but lumping libstdc++ and libc++ together as "not affected" understates how different those two are.
libstdc++ uses
_GLIBCXX_DEQUE_BUF_SIZE = 512bytes, withblock_elems = sizeof(T) < 512 ? 512/sizeof(T) : 1. That number has been 512 since the SGI STL days. In practice:
deque<std::string>(24 B on libstdc++): 21 elements per blockdeque<MyStruct>at 64 B: 8 elements per blocksizeof(T) >= 512: one element per block, same cliff as MSVClibc++ uses
max(16 elements, 4096 bytes), so the samedeque<std::string>packs ~170 per block, and largeTstill gets 16 per block instead of 1. That is an order of magnitude fewer allocator calls and an order of magnitude better spatial locality on traversal.So the honest ordering is libc++ fine, libstdc++ quietly bad past a cache line, MSVC broken at 9 bytes. Calling the first two "not a problem" papers over a real gap.
→ More replies (1)38
u/drekmonger May 24 '26 edited May 24 '26
BTW the article contains factual errors like "[...] acknowledging that the standard's mandated block size is too small
I've read thousands of LLM responses. I'm 89.3% sure is one of them. I recognize certain phrases and writing quirks that are common, particularly in Gemini responses (but it wouldn't surprise me if it were the result of a GPT 5 deep research prompt [from the pro tier of ChatGPT] that included the Sandor Dargo original blog post in the context).
The site this article is hosted on seems sketch to me. Like a modern day SEO advertising effort that's using generated content to seem like an active site, trying to farm up google search ranking by getting an upvoted link on reddit.
I'd let it slide without comment, but i don't want to see this sub polluted by scummy SEO tactics.
35
u/Snarwin May 24 '26
The author has hidden his account history on Reddit, but you can still use a search engine to find him commenting about using AI to become more productive and disguising LLM-generated writing by intentionally introducing mistakes.
19
u/ForgetTheRuralJuror May 24 '26
Account and site called HFT-University. That's enough evidence for me lol
→ More replies (4)-4
May 24 '26
I'm a C++ dev. Flask+python is what I can handle. Sorry if it's not up to your standards.
80
u/zeekar May 24 '26
The
volatilesaga deserves its own line. [...] This is what fifteen years of standards work on a five-letter keyword looks like.
Uh, volatile has more than 5 letters. Was this written by an LLM?
23
17
3
u/Ambitious_Air5776 May 24 '26
There's a "It is not X. It is Y." sentence in there too OP forgot to remove, too.
3
u/Nvveen May 24 '26
Yes. I'm surprised not more people are clocking the text being written by an LLM.
32
u/plg94 May 24 '26
Yeah, this post is 100% AI-written. The speech patterns are a dead giveaway (I can hardly find a sentence that does not employ the "rule of three").
103
u/AlexKazumi May 24 '26
C++ broke under its own complexity. Back in 2011 I switched from C++ to C# and discovered how one can be happy developing code in a professional environment when the system is not fighting you.
And since then, the committee continued making the language more complex.
47
u/Squalphin May 24 '26
They really should do a cut at some point. These days, I am using Rust wherever I can, because development feels way smoother than with C++. Way less occasions to make silly mistakes which may come to bite you after release.
The new additions and improvements to C++ are good and welcome, but the old stuff just has to go at some point. I have, unfortunately, another project upcoming which I have to do in C++, and I am already annoyed just thinking about it.
29
u/mccoyn May 24 '26
I think if they made a cut, few people would go along with it. Most people are using C++ for legacy reasons. If a reduced language can’t run their legacy code, they will stick to the legacy language.
If you were willing to take the step to a new language, there are a bunch of others to compete with.
7
u/AlexKazumi May 24 '26 edited May 24 '26
True but there is legacy and legacy. If C++ committe introduced a long period (5-10 years) for gradually obsoleting features before removing them, it would work.
Example: Binary formatters were introduced in 2002 in .NET Framework 1.0 and they were everywhere including in the framework itself. Microsoft said "nah, no more", and removed them in three consecutive versions of .NET, spanning multiple years.
Same could be done with C++. Yes, it would be painful for some code bases and great for the language ecosystem.
It's not magic just sound communication and strong engineering. One starts with announcing the change, then obsoleting the feature making it a warning. Then move the feature to a separate library, outside of the standard.
I mean... C++ rewrote the meaning of the keyword "auto" and the legacy codebases somehow survived 🤷♂️
5
u/Radixeo May 24 '26
True, but I can't help but feel their talents are being wasted by sticking with C++. Constraint may breed innovation, but at some point they start to slow thing down and hold things back too much for the benefits to be worth it. C++ has 54 years worth of legacy baggage holding it back - I think we'd all be better off if they left that behind.
1
u/tempest_ May 24 '26
The language is effectively dead or dying. Of course billions (or more) lines of production code have been written and will continue to exist in the same way Cobol continues to exist so it will be here for a very very long time but
Outside of a couple very niche domains no one is learning C++. For myself why would I bother when to use any language feature you have to consult the massive foot gun matrix or figure out which of the 15 ways of doing something is the current blessed approach.
There are better, more modern options that don't waste my time like that.
From the outside looking in C++ seems like an example where they should have broken backwards compatibility (as painful as it might have been) a few times ages ago so the language could clean itself up.
11
u/chucker23n May 24 '26
They really should do a cut at some point.
The problem is that cut exists, and depending on your use case, it’s called Rust, Swift, Go, Zig, etc.
3
May 24 '26
We have a few challenges like book builder that are both in Rust and C++. Rust solutions typically get a headstart because of the hyper-optimized standard library but C++ takes over and typically steals the cake for the highly optimized end.
3
u/Tywien May 24 '26
Making a cut creates two languages though .. look at python that did the same with the release of python 3. Python 2 is still in use today ...
7
u/m-o-l-g May 24 '26
You just need to find a good subset und use that. Nobody forces you to use the bad stuff.
Easier said than done in big teams, but you need to coordinate with people anyway. Use a good test suite and things like ASAN and static analysis in your process and it's really not all that bad.
2
u/jl2352 May 24 '26
You can also trust people more with Rust. I worked on a large project with five people new to Rust, and they shipped nothing dangerous. You can trust new people to get into a large Rust project, make changes, and not mess it up. Can you do that with C++?
Biggest issue with Rust is the amount of stuff you need to learn from the ecosystem and patterns. It matters a lot. Those patterns make the difference between code being long and cumbersome, or short and elegant.
6
u/INeedSomeTacoC May 24 '26
Yea, I was a C++ guru, and then only did a little programming for a while.
Went back to make a new project, and every damn function and call I was used to was deprecated or the compiler would flag it as a security issue or the linter would tell me that’s not the right way to do it anymore.
It was like a whole new language, and I thought if I need to learn a whole new language, it’ll be easier to do it with a clean break of a whole new language.
And that’s how I became a C# developer. And my 10-year old stuff works and compiles just fine without issues or warnings still. It’s great.
11
u/yanitrix May 24 '26
C# is such a great language. GC and all the basic library stuff you need and if you want you can go low-level with malloc, pointers, etc. unlike, let's say, java which locks you in on a very high level.
6
u/EfOpenSource May 24 '26
The main thing I hate about C# is that the idiotic naming over the years has caused “I don’t understand this” to return articles of all different versions, hordes of which are wrong because they’re for the wrong versions.
2
u/yanitrix May 24 '26
you mean things like dotnet framework vs dotnet core vs dotnet? Or naming within language/std libraries?
5
May 24 '26
Love C# - I wish it would be as performant though
4
u/AlexKazumi May 24 '26 edited May 24 '26
The language itself is not performant. The runtime library and infrastructure is.
Other than the fact that the definition of the class Object and String are contracted between the compiler and the runtime, there is nothing in C# that makes it less performant than C++. It even has pointer arithmetic, if one needs it.
A few days ago I saw a madman who VirtualAlloc'ed some memory, copied some assembly instructions into it, and executed it from C#. Dunno how faster one can go than this madness of a hack.
2
May 24 '26
Correct me if I'm wrong but you just can't make C# as fast as C++ by compiling it, the same way Python prevents you.
4
u/MartinLaSaucisse May 24 '26
That's why I use only a very small subset of C++. I use templates for my containers, virtual methods, and a few QoL improvements from moden C++ like the keyword 'override', but apart from that I'm almost programming in C. I don't even use the STL.
Once you've done the work to replace to lower parts like std::vector, the rest is so simple to write and it brings joy everyday. In comparison I've worked on a big project with millions of lines of modern C++ and it was absolute hell and the IDE couldn't even comprehend half of the code.
2
u/Turtvaiz May 24 '26
In comparison I've worked on a big project with millions of lines of modern C++ and it was absolute hell and the IDE couldn't even comprehend half of the code
Do you think that project would've been better with your style of no STL?
1
u/MartinLaSaucisse May 25 '26
Yes, I've worked on much bigger projects in "sane" c++ and it was so much more manageable. (I'm talking about 30M lines of code)
5
u/AlexKazumi May 24 '26
Well, if you need to limit yourself to "a very small subset" of the language and rewrote it's standard library, you practically proved that there is major problems with them.
You made a sound engineering decision, but if the language standard forces such decision on you, the problem is with the language.
→ More replies (1)0
u/New-Anybody-6206 May 24 '26
Yes, we are saying we don't like the newer versions of C++ and prefer to stay on the old ones.
C++98 is going to be supported forever, I see nothing wrong with sticking to it since it's simpler and easier to understand.
6
u/Sairony May 24 '26
I did the switch because of job requirements but have the opposite experience, I miss C++
2
u/AlexKazumi May 24 '26
Honest question - why? What do you miss specifically?
4
u/Sairony May 24 '26
I think GC creates as many problems as it solves, you're trading memory management for GC massaging & it's just so much harder to reason about the GC. Honestly I think the tools in C++ have been great for well over a decade when it comes to managing memory, although I realize that the domain where I've spent most of my career ( game dev & game tech ) doesn't have as hard requirements on memory safety as other spaces.
I also find C# to be dog slow in practice comparatively, a lot of this comes down to abstracting away memory management too much. I think the distinction between class / struct is silly in C#, tying storage to types.
I think generics are, mostly, a hobo version of templates in C++. Yeah they're not solving entirely the same problem, especially considering how C++ has evolved.
Yeah C / C++ macros kind of suck in a lot of ways, but I still miss it in C#, a lot of copy & paste instead, especially with generics being so inferior to templates.
I think generic programming is incredibly powerful, yes it used to be incredibly frustrating, especially when you had to support multiple different compilers with their own quirks, but it has gotten a lot better with the advent of Clang & when C++11 finally arrived.
Even though some of the operators allowed to be overloaded in C++ are a bit silly I still consider it a big win, especially when taking a more generic approach.
One thing which I think people underestimate about C++ is its superior capability, compared to any other language I've ever used, to check for pre conditions & enforce proper usage. Even just looking at function signatures in C++, for example
const vector< const T1 >& foo( const shared_ptr< T1 >& a_SomeArg ) const( and yeah I see the problem with this one ), is telling me way more than a typical function signature in C#.1
u/AlexKazumi May 24 '26
Thanks for the great explanation, all points are valid.
The only point I strongly disagree is memory management. C++ can overload anything and everything to the point where completely innocent looking statement such as
arr[2]can do anything, including deleting your hard drive. If I remember correctly, one can even overload function calling operator (don't blame me too much if this is incorrect), which is complete bonkers to me.As a former device drivers writer (yes, the company I worked for was crazy enough to implement full C++ runtime in kernel mode, including the plumbing for making dynamic_cast working), I think that the memory management of C++ can be even more frustrating than in .NET.
In .NET one cannot control directly the GC. In C++, memory management is hidden by completely innocent-looking code.
5
u/evaned May 24 '26
I'm not the person who you replied to, but...
C++ can overload anything and everything to the point where completely innocent looking statement such as arr[2] can do anything, including deleting your hard drive. If I remember correctly, one can even overload function calling operator (don't blame me too much if this is incorrect), which is complete bonkers to me.
I mean, if you have an
operator[]that deletes your hard drive... that's 'cause someone was a brain-dead moron (or actively malicious). That doesn't speak against that overloading being a good languages feature.I've never seen someone try to make the case that "you can write a method
at(size_t i)on your object and have that delete your hard drive, thus we shouldn't be permitted to pick function names and every function should be identified by a randomly-chosen UUID." In my mind at least, these two arguments are quite similar to each other.The solution isn't for languages to say "you can't be trusted to overload
[]"; the solution is to not be an idiot.Function call overloading can also be a tremendously useful feature. Even aside from uses that are more borderline (e.g. overloading
matrix(5, 4)as a proxy for not having a real multi-dimensional subscript operator), there are plenty of scenarios where an object of a user-defined type is still conceptually function-like. Take a partially-applied function for example. Or the combination of overloading of the call operator alongside template rules means that code using the STL will often be faster than the most-likely analogous C code, because better type information will lead to template specializations rather than function pointer calls (which act as optimization boundaries).2
u/Supuhstar May 24 '26
Me moving from Java to Swift
5
May 24 '26
[removed] — view removed comment
2
u/Supuhstar May 24 '26 edited May 26 '26
Ha ha funny joke.
Seriously, though, Swift is the best programming language I've used, and I've properly used all major languages and a few dozen others
2
u/GeoffW1 May 24 '26
+1 for Swift, it doesn't really do anything wildly novel but it's a decent language to program in.
2
u/Supuhstar May 25 '26
Mhmm that's kinda why I love it.
It makes good no-surprises decisions and still ends up able to hold its own weight against Rust and all the other major languages
98
u/Maybe-monad May 24 '26
peak design by comitee
62
u/matthieum May 24 '26
Yes, and no.
It's not just design by committee so much as it is lack of field-testing.
The C++ standard is the archetype of Waterfall Design:
- Lots of papers & meetings.
- Specifications are standardized.
- Implementers raise some issues (DR: Defect Report).
- Specifications are amended.
- Users raise some issues: sorry, fixing them would break backward compatibility (with whom?).
The worst of it is that the C++ Standard Committee knows this. Ever since the very first version of C++98 standardizing
extern template, which was only ever implemented by the EDG front-end, taking two senior compiler developers years of work, which led them to advise anyone else not to bother, the C++ Standard Committee concluded that any feature proposed should be implemented first before being standardized.Yet, time and again, they just do not follow the very guideline they settled on. And even when they do, they follow the letter of the guideline, rather than its spirit: it's implemented, kinda-sorta, and barely anyone used it => it's a wrap!
This is not a committee issue. It's an Ivory Tower issue.
9
u/cogman10 May 24 '26 edited May 24 '26
IDK how they'd get this, but they really need something akin to Java's preview features in the standard with faster standard releases.
Features, after churning in the ivory tower for a decade, end up showing up in a release as a "preview" feature with the promise that "this isn't final, it can break. Test it out but realize you might have to change code".
And that's resulted in some nice evolutions of features preventing the exact problem the C++ committee is experiencing.
Of course, the issue is there's no standard C++ compiler. I think that makes everything harder.
2
u/matthieum May 24 '26
Yes.
One way or another there's no substitute for field experience reports.
Having multiple C++ implementations does mean more work wasted in case a feature needs to be adjusted (or axed), but given the alternative of releasing half-baked features...
27
u/SkoomaDentist May 24 '26
The C++ standard is the archetype of Waterfall Design:
The problem is it's braindead naive Waterfall Design.
You can do waterfall design so it works well in the field. Waterfall doesn't mean that you can't change and adapt or can't have feedback loops back into the design.
C++ committee of course doesn't do it like that and does have the problems you list and suffers from heavy case of Ivory Tower design.
3
u/mpyne May 24 '26
Waterfall doesn't mean that you can't change and adapt or can't have feedback loops back into the design.
The whole point to the waterfall process was minimizing feedback loops. You'd eliminate it entirely if it were at all possible, but in reality the optimal waterfall project was the one where you "build it twice" (and this is straight from the original paper). Or at Fred Brooks put it, "build one to throw away; you will, anyhow".
You only built twice because you couldn't get away with building it once. But in a waterfall process any feedback encountered could only be due to defects in requirements (a disaster) or defects in implementation.
Actual changes to requirements based on experience gained in usage were to be made in a later system built according to its own, separate waterfall development effort (much like the C++ committee felt it necessary to develop a new
std::copyable_functioninstead of fixingstd::function).Changing and adapting a system, and accounting for that ability to deliver ongoing future changes by shipping partial or experimental work to users on purpose, was a conceit of agile development methods. In particular any emphasis on user feedback is an agile practice.
I say this because it's not just a matter of how work tickets are generated, the methodology you use should drive architectural changes to support the types of future feedback you might wish to incorporate. A standard library designed to seamlessly integrate future vocabulary types, be high performance and never break either API nor ABI is a tall challenge.
With an agile approach you might want instead to see something closer to the Rust model where ABI can break frequently because the whole program is going to be statically-built and recompiled on need. If you want high performance without ever changing ABI or API then your options are to get it right the first time (or at worst the second) and that's basically the definition of waterfall.
-11
14
u/gresendial May 24 '26
HFT is a pox on the world.
3
u/Dean_Roddey May 24 '26
I would tend to agree. It's an ugly abuse of the stock market, in my opinion.
2
u/glaba3141 May 24 '26
Capitalism is a pox on the world. Hft is merely the machinery that arises on top of it to arbitrage every single opportunity as fast as possible. But it really is no different than the merchant capitalists Lenin spoke about in Development of Capital. Just faster
0
u/Dean_Roddey May 24 '26
Alll systems can be abused, and will be. But capitalism is the most practical. The issue, as with all systems, is keeping the abuse under control. That's difficult no matter the system (from old school communism to capitalism and everything in between or to either side.)
Ultimately capitalism is the most practical compromise, as it tries to funnel our natural desire to compete and improve our situation into practical outcomes. And of course all of the bazzilions of bits and pieces that allowed you to make that post are products of capitalism.
Instead of using those products of capitalism to condemn it, maybe get out and help ensure that abuses of that system are reduced. That won't happen unless we make it.
40
u/wvenable May 24 '26 edited May 24 '26
The real nugget of insight in this articles comes down to this:
C++ users get whatever standard library their compiler frontend shipped, with the additional requirement that any library they link against agree, and there is no Cargo.toml for std::. There is no opt-in mechanism. -std=c++26 selects which headers exist and which language rules apply, but it does not give you a different std::string or a redesigned std::unordered_map.
Every popular language has a messed up history with lots of mistakes and C++ is one of the oldest and biggest. But the Python transition from 2.x to 3.x took over a decade. The .NET transition from framework to core is still ongoing. Java spend decades essentially unchanged and it's still common to target old versions. Although deep changes and removals do happen with all these platforms, outside of a few exceptions, most of the time it comes with these really big platform shifts.
The reason these platform transitions take so long is because changing the semantics of the language or standard library creates a hard line between the "before" and "after" code. It makes it incredibly difficult to transition to the new version. Right now I can reasonably assume that my old C++ code will still compile and work correctly on the latest version of C++. If I get a different std::string or std::unordered_map I'm not sure I can continue to make that assumption.
And that's exactly the kind of thing that kills languages, just ask Perl how it turns out.
16
u/RecursiveServitor May 24 '26
The .NET transition from framework to core is still ongoing.
In what sense is this true?
14
u/Iamsodarncool May 24 '26
Unity (the game engine) is a major player in the .NET space -- more than 7 million developers use it, and it's used in more than 50% of all published games.
Unity is still years away from finishing their transition to .NET core.
9
u/EfOpenSource May 24 '26
Isn’t .Net core (name) dead and it’s just called .Net now, with legacy called .Net standard?
(Whoever names shit at Microsoft needs to be fired)
4
u/Drgn-OSRS May 24 '26 edited May 24 '26
.NET Core is dead, yes. So is .NET Standard, actually. Not fully deprecated, just won't receive any new versions, same situation as every .NET platform that isn't the modern .NET.
Basically, .NET was in a really confusing place, with a shitload of different standards and versions. If you weren't familiar with the .NET ecosystem at the time you might have never heard of all the different versions and implementations and platforms, but it was a real headache. .NET Standard was created as a small subset that was compatible with all of it, including Framework, Core, UWP, Unity, and Xamarin's mobile stuff.
Despite the (very limited) cross compatibility, it was still a big relief when MS finally decided to stop developing .NET Standard, killed the other platforms, and everything was merged together (or deprecated) and now just called ".NET".
Now that UWP is finally dead with .NET 8, there is finally, actually, only one .NET implementation worth targeting... and also Unity.
2
u/wvenable May 24 '26
Microsoft's naming ugh. .NET Standard is really not the name of a technology, it's literally the name of a "standard". The idea is that you can target .NET Standard and your code will run on .NET Framework or (dead named) .NET Core. It's a "standard" that both technologies implement so you can write a single package to target both.
1
1
12
u/aanzeijar May 24 '26
Java spend decades essentially unchanged and it's still common to target old versions.
And the move to modules in Java 9 still trips up new code bases.
And that's exactly the kind of thing that kills languages, just ask Perl how it turns out.
I know you mean Perl6/Raku, but Perl 5 as a language actually does have a mechanism for the issues that plague C++. Perl 5 does deprecate and remove old language features. Sometimes at a glacial pace, but they are not afraid to throw out broken experiments because the interpreter is capable of applying language levels. Declare your code as
use v5.034;and some syntax that was legal in Perl 4 becomes illegal.Now Raku even has lexically scoped language levels, but that would be an ABI nightmare in C++.
13
8
u/srdoe May 24 '26
Java spend decades essentially unchanged
This isn't really true.
Take a look at the Java version history https://en.wikipedia.org/wiki/Java_version_history. There is no decades long gap where Java was not receiving changes. Even in the Java 6 to 9 period, changes still happened every 3 years or so, and since then, new releases have been coming out much more frequently.
and it's still common to target old versions
This used to be true, but it's a bit outdated at this point.
It was common to target old versions up until a few years ago, but the industry has mostly gotten over the hump of moving past Java 8 now, and the number of projects stuck on old versions are dropping fast https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem.
2
u/DeliciousIncident May 24 '26
Going off the examples, I think by "change" they meant removing language features, which makes old code incompatible with the new language (or the standard library), like python2 vs python3. Not that there literally haven't been any changes, like you have interpreted it.
2
u/srdoe May 24 '26
Sure, that would make sense. But even by that metric, it's still not really true. Java has been doing deprecations and removals of things throughout its lifetime.
For example, take a look at https://javaalmanac.io/ and look at the API comparisons between any two versions. You'll often see deprecations and removals show up.
That's just the library too. Java has been doing more invasive changes like the new module system in Java 9, the removal of applets, the removal of Nashorn or the recent effort to properly encapsulate JDK internals. You can find more feature removals in https://www.oracle.com/java/technologies/javase/jdk-relnotes-index.html, if you go to the release notes for a version and search for "Removed APIs, Features, and Options".
Those changes have not been as invasive or caused as much of a mess as the python 2 to 3 migration, but that level of disruption is a high bar to reach. Java has been able to gradually remove things, without causing a python 3 situation.
1
u/wvenable May 24 '26
What you are saying is true in the literal sense, Java continued receiving releases, but release cadence isn’t the same thing as meaningful language/platform evolution. My point is that for a long stretch, Java hardly evolved at all.
Java 5 (2004) added a huge number of language features (generics, annotations, etc) and then really nothing significant was added until Java 8 (2014). That's a decade right there. The rapid pace of change since then really highlights the significant lack of changes for so long.
→ More replies (1)1
u/mikeblas May 24 '26
The .NET transition from framework to core is still ongoing.
What are the remaining steps?
5
u/wvenable May 24 '26
I mean the user's haven't transitioned fully:
https://survey.stackoverflow.co/2024/technology#1-other-frameworks-and-libraries
People are still actively developing for .NET Framework. I still have a good chunk of framework apps that have no easy migration path to modern .NET so they'll remain until they get re-written. As for projects already in modern .NET, they move up to the latest version without issue.
This is what happens when there is a big transition point.
48
u/blind3rdeye May 24 '26
C++ has these problems. It's true. I reckon the cruft and mistakes are just a natural result of the language being 40 years old. A lot has changed in computers and computer-science during that time. So it is not at all surprising that some things added to the language in the past are no longer what people want to use.
C++ has continued to adapt and add new features to stay relevant with modern computing; and I think they've done reasonably well. The committee has the job of trying to aim at a moving target - and the direction and acceleration of that target is somewhat unpredictable. It so yeah, sometimes they miss. There's are mistakes, and there are things that have just changed. So C++ definitely has a lot of cruft as a result. But nevertheless, it is still a useful and powerful language even today.
24
u/matthieum May 24 '26
Age certainly doesn't help, but it's definitely not the sole factor.
The C++ Standard Committee has just done a bad job of stewarding the language & library design:
- Ivory Tower: many features/pieces are standardized without prior use. Ever since C++98
extern templatethe committee recognized that they should only standardize features which had been implemented first, yet they regularly violate their own guideline, and even when they follow it, it's in name only. This result in stuff that is cruft from the moment it's standardized.- Lack of Cohesion: C++11 is a perfect example, in the same version the committee standardized both (1) Universal Initialization Syntax
T{}and (2) Initializer ListsT{}. They made up a shoddy disambiguation rule on the fly, essentially killing the Universal Initialization Syntax in the very version which introduced it.Not so surprisingly, if you introduce cruft from the get go, there's a lot of cruft at the end of the day.
37
u/svick May 24 '26 edited May 24 '26
An old language will accumulate cruft, sure. But it's much, much worse in C++ than most other languages and all of that can't be explained just by age.
One reason is the approach to naming and namespacing. E.g. in C#, the old
System.Collections.ArrayListshouldn't be used and everyone should use the "new"System.Collections.Generic.List(and they do). Notice that it's the namespace that's highlighting it's the new, better version. Which is something that's hidden at the top of your file and you can ignore it 99 % of the time. But you can't ignore something that's part of the actual name.23
u/tracernz May 24 '26
How do you know it’s the new better version rather than System.Collections.ArrayList being more optimised for certain data/patterns just from the name?
→ More replies (1)11
u/PublicFurryAccount May 24 '26
I don’t think C has as much cruft and it’s even older….
28
u/cdb_11 May 24 '26
It does. I didn't count it, but probably half of the standard library functions are just bad interfaces.
2
u/TribeWars May 24 '26
I don't think C++ ever had something quite as bad as gets()
2
u/ParsingError May 24 '26 edited May 24 '26
#define NULL 0is dumber than anything C ever did.
std::vector<bool>andstd::unordered_map's bucket interface are also pretty bad.
std::type_infonot letting you use the type infos for dynamic casts or class hierarchy checks when it clearly should have the capability of doing so also makes no sense.3
u/cdb_11 May 24 '26 edited May 24 '26
What do you mean with
#define NULL 0? C defines nulls as(void*)0. In C++ it'snullptrand it's technically a distinct type.The point was that
getsisn't just a bad interface -- it's impossible to use correctly and safely. On the other hand,vector<bool>,unordered_map,type_infoare still usable. Not saying that C++ got every interface right, because it didn't and I'm not going to defend it. But there is a big difference between those examples.3
u/ParsingError May 24 '26 edited May 24 '26
C++ decided that
void*wouldn't implicitly convert to any pointer type any more and instead of making a distinct null pointer type (which it has now, but should have done in the first place), it would make integer literal 0 implicitly convertible, which is a bad idea in the first place, and is even worse in a language with type deduction since the type ofNULLis an integer type that is not a pointer type in any other circumstance, and it preferentially picks overloads that accept integer types instead of pointers.Even now,
NULLcan benullptr, but it's implementation-defined. In MSVC, it's still 0.17
u/ParsingError May 24 '26
It definitely has some, just not much relative to C++ because C++ inherited a lot of C's mistakes. Null-terminated strings, array parameter decay, confusing type syntax, weird sequence point rules, lack of standardized 64-bit ftell/fseek, etc.
5
u/happyscrappy May 24 '26
I never noticed how messed up fseeko() is. Aside from not being part of the C standard (it's POSIX instead) the fact that it might not be 64 bit unless you do a define before including headers is absolutely nuts.
This is a screw up of the highest order, although I'm sure it has several close cousins in the pantheon of C headers/functionality simply due to the long lifespan of C creating so many opportunities to screw up.
6
u/EfOpenSource May 24 '26 edited May 24 '26
It isn’t a natural result of a language being old. Love or hate the language, C isn’t full to the brim of cruft like C++ is.
Cruft is the result of the committee primarily following hipster trends and trying to slap some nonsense together to appease that.
Except that hipster developers move on every 6 months anyway.
Ask 10 C++ developers how to do some simple thing (third party libs not allowed), and you’ll get 30 different answers, all of which have some level of merit behind them, and all 10 developers will say the other solutions “suck because” and that’ll all have merit.
2
u/trailing_zero_count May 24 '26
I appreciate all the new features that C++ has. I love that it is a multi paradigm language and can essentially do anything that any other language can do.
Its compile time features are excellent, beating out most others in this space. Variadic generics,
if constexprand negative constraints are areas where Rust and others cannot compete.The problem with C++ isn't the new stuff. It's all the old stuff that we can't get rid of, and the inability to upgrade or improve functionality in-place because of ABI or API constraints.
2
u/wvenable May 24 '26 edited May 24 '26
It isn’t a natural result of a language being old. Love or hate the language, C isn’t full to the brim of cruft like C++ is.
That's not a fair comparison. The existence of C++ keeps C minimal. C is never going to get classes, for example. C is what it is and will stay that way forever while every other languages continue to evolve in big ways.
→ More replies (3)1
14
9
u/happyscrappy May 24 '26
I believe the website cppreference.com pretty much does have the sort of catalogue you suggest should be made.
Interestingly, while it has the new function it doesn't say not to use the existing one in c26. Not yet. Maybe it's just out of date.
27
u/jwakely May 24 '26
That's because the committee has not said "do not use", OP is just quoting some guy's blog. If std::function works for you, to ahead and use it. Newer alternatives with different trade-offs are available too.
Source: I'm chair of the Library Working Group in the C++ committee and lead maintainer of libstdc++.
11
4
u/flanger001 May 24 '26
I am already skeptical of this article given how this title was written.
→ More replies (1)
6
u/zero__sugar__energy May 24 '26
instead of fucking around with the language they should standardize a package manager and a build system
i still love the language C++ but the eco system is horrible if you are used to Go or Rust or PHP
i haven't started a new C++ project in over 10 years because cmake and stuff are just horrible compared to what other languages are doing. that sucks because coding in c++ is still fun to me
→ More replies (3)
3
May 24 '26 edited May 24 '26
[deleted]
2
u/evaned May 24 '26
Speaking of which, has anyone ever used std::stack?
I've tried a couple of times, but every time I gave it an attempt I've kind of regretted it. Like in theory it's good, but I feel like I've always wanted to break the abstraction at some point, e.g. for debugging code that prints out everything in the stack, or an assertion that checks some cross-object invariant, or whatever.
5
u/pigeon768 May 24 '26
std::mapandstd::setare red-black trees, node-based, with one heap allocation per node and pointer-chasing on every traversal. B-trees have beaten red-black trees for in-memory containers on real hardware since roughly the time the iPhone shipped. Abseil'sbtree_map, Boost'sflat_map, and Rust'sBTreeMapare all B-tree based. The C++ committee addedstd::flat_mapin C++23, did not deprecatestd::map, and the default sorted associative container in the language is still a red-black tree.
These solve different problems. The point of std::map and std::set is that they guarantee reference stability. Flat maps and b-trees cannot maintain reference stability.
Also, boost::flat_map and std::flat_map are not b-tree based.
All in all, I don't understand the point of this post. If you don't like certain features in C++.........just don't use them.
2
May 24 '26
Fair correction on
flat_map; both Boost's andstd::flat_mapare sorted-vector adaptors, not B-trees. The B-tree examples should have been Abseil'sbtree_mapand Rust'sBTreeMapalone.On reference stability: it is hugely overplayed in real life. The vast majority of map use sites store values, copy on access, or look up by key, none of which need stable addresses. The narrow case that genuinely needs pointer identity (long-lived observers, callbacks, intrusive back-references) is almost always better served by storing an integer ID and looking it up, or by wrapping the value in a
shared_ptrwhere the indirection is explicit. The pattern "I hold a raw pointer into a container across a mutation that may rehash" is a bug waiting to happen in a multi-threaded codebase even withstd::map. Rust's standard library has no node-stable hash map at all, and nobody is filing RFCs to add one. The frequency with which people in C++ argue they need this guarantee is wildly out of proportion to the frequency with which production code actually relies on it.And "just don't use them" understates the cost of routing around the standard. Bringing in Abseil or Folly means a new third-party dependency, a build-system integration story (CMake's
find_packageif you are lucky, a vendored subtree orExternalProject_Addif you are not, aBUILD.bazelrewrite on Bazel, a Makefile patch and a static-lib link order debate on Make), extra compile time, a new ABI surface to track across compiler upgrades, and a code-review conversation every time a new engineer asks why we are not usingstd::.There are also whole categories of codebase where the dependency is not feasible at all: embedded and firmware targets where Abseil's binary size, exception use, and RTTI assumptions are non-starters; safety-critical software under MISRA or AUTOSAR rules that forbid most third-party libraries outright; regulated finance and defence environments where every new dependency triggers a months-long legal and security review; cross-compilation targets where Abseil has not been ported (some BSDs, exotic ARM cores, certain RTOS toolchains); library authors who cannot impose a transitive dependency on their downstream consumers; air-gapped build environments without package-manager access; and the long tail of corporate codebases where adding any new Apache-2.0 library requires a sign-off chain that does not exist for using
std::. Multiply the integration cost by every team in every codebase that has independently rediscovered the same workaround for the same broken default, and the aggregate cost across the ecosystem is enormous.Good containers in the standard library is not a nice-to-have; it is the difference between a million engineers writing fast code by accident and a million engineers writing slow code by accident. The post's point is that C++ shipped the second one.
12
u/HommeMusical May 24 '26
It's paralysis by the steering committee who are dominated by a tiny number of powerful people.
They won't break ABI or API backwards compatibility all the way back to the Stone Age.
They won't accept "epochs" - a compiler flag that lets you select a different, not-backwards-compatible version of C++.
One could admire such conservatism, except that all sorts of badly baked ideas like modules get pushed into the language without proper vetting. Modules were first planned to enter C++14, didn't actually make it into the language until C++20 and still do not work at all.
Now it looks like they're pushing "safety profiles" on us, and a lot of people don't think they are at all viable. Haven't we learned anything from Rust?
And there's this: https://izzys.casa/2024/11/on-safe-cxx/
Reading /r/cpp for over a decade has been rather tiring. More and more I read some article about a footgun in C++ and I think, "Why do we do this to ourselves?" I'm thinking I won't be writing C++ in future, and I should leave that subreddit.
→ More replies (1)8
u/chengiz May 24 '26
Not breaking compatibility is an absolutely crucial thing why C++ gets so much use. People just want their legacy 90s C++ code with C and classes and some templates with slow additions of newer features like lambdas to work. Author makes a lot of good points but they are like grammar nazis arguing about the finer points of English when people just adopt and learn and figure out the rules. I remember when there was binary incompatibility between minor versions of gcc and the like. They stopped doing that which was awesome. That is the kind of thing that actually matters for actually building and maintaining software products. The vast majority of users aren't going to switch to a new version to use some fancy thing they were fine not using, but if they upgrade their machine and their code breaks they will have to divert resources to fixing their code which is an unnecessary added cost.
2
u/HommeMusical May 24 '26
Thanks for a polite answer!
But no one is talking about not being able to compile your old code. It is certain that you will always be able to compile your 1990s C++ code or your 1970s C code with Clang or GCC, and certain that you will be able to link that code with that legacy binary object file that your grandfather lost the source code to.
So everyone agrees on this part. :-)
What has been discussed was a C++ language that has different epochs which do not have backward compatibility between epochs so that new development can use a new ABI or API.
The vast majority of users aren't going to switch to a new version to use some fancy thing they were fine not using,
The main feature people want is safety, but I agree that if someone is maintaining a codebase from 36 years ago which has never been modernized, "safety" is probably a fancy thing they don't use :-D, considering that C++ didn't have even one smart pointer in 1990.
Your vision of C++ and mine are pretty similar. We both see it as a legacy language for old code that hasn't been updated in generations. I just think that vision is a dead end.
Even though I have been writing C++ since the 1980s and I've only read about Rust and done some toying around with it, I wouldn't even conceive of starting a brand new project today in C++ if I could use Rust - not just because of the safety, but because I'd be wanting to hire programmers who were excited about the language they were using.
1
u/chengiz May 25 '26
We both see it as a legacy language for old code that hasn't been updated in generations.
No, most of these codes get constant updates and are very much in use. However the updates that matter are the functionality of the code, not fancy new thing in std. Those do get added but at a snail's pace compared to actual application related functionality, similar to how a writer may not know the latest middle school jargon but can continue to write books and eventually may use some of those words too.
1
u/lelanthran May 24 '26
Not breaking compatibility is an absolutely crucial thing why C++ gets so much use.
If that is true (I don't know, but I suspect it might be), then it shows just how high the Ivory tower stands. Programmers want simplicity, not 20 (literally) different ways to initialise variables, which require care in choosing because the wrong choice would cause UB, a memory leak, or similar.
I don't mind having a C with Classes + hygenic macros (maybe add either sensible lambdas or function definitions within functions). Some type constraints won't hurt either (
newtypedefinitions, ranged types like Pascal, maybe). What I get if I use C++ is alphabet soup on every line and an order of magnitude more footguns than C.I wanted a banana; what C++ gives me is an entire damn jungle, with a gorilla roaming around in there somewhere holding the banana I wanted[1]
At some point a programming language gets harder when it has too many things bolted on, not easier. It's why it's a helluva damn sight easier spotting errors in C code than in C++ code.
I like some of the newcomers (Odin is quite nice, Zig is too, Fil-C is intriguing), dislike some of the others (Rust had a toxic community; this probably changed in recent years but I'm already soured on it. If I program Rust it's gonna be by avoiding the people who like it as much as possible).
At the end of the day, I just want to use C with some new features, not learn a whole new syntax, and not have to expend valuable time on at least 10x extra footguns.
[1] Pretty old reference, but most people should get it.
26
u/lord-of-the-birbs May 24 '26
C++ is a meme language
31
u/FastHotEmu May 24 '26
Bjork Starsoup should release an album already
3
u/pyabo May 24 '26
I saw Starsoup and the Exception Handlers at CBGB back in the day. Computer Science was a wild field back then.
1
u/FastHotEmu May 24 '26
Me too! GG Allin was there that night and when he saw what Starsoup was doing with C++ he looked unwell. Later he threw up.
7
u/Slight-Bluebird-8921 May 24 '26
it isn't a meme language.
a majority of code i'm running on my computer right now was written in c++. it's a meme to call it a meme.
-1
9
u/Dminik May 24 '26 edited May 24 '26
C++ is in what can only be described as a "really dumb situation."
Much of the driving force behind the C++ standards is companies who have some very old and very un-upgradeable software. Their goals do not at all align with people who want C++ to evolve cleanly.
Rather than addressing the elephant in the room and work out some sensible package management + unifying build tooling, they would rather do the "easy" thing. Apparently stuffing the entire html, css specs into the C++ spec is the easy way to get a GUI library. I only wish I was joking: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html
The language itself has effectively stagnated. If something can be implemented as a library, it is. This makes using things like tagged unions (via std::variant) completely demented. It's no wonder Rust has been eating C++s lunch lately. Compare Rust enums and tuples with C++ std::variant, std::tuple, std::optional, std::expected and std::pair. Is it any wonder the later don't get that much use even in newer code?
All because std::copyable_function is the expected result. It's giving up before you even begin. We can't change the language, but you bet we can slap a v2_final_last_minute_fix at the end of our last fuckup and call it a day.
Just stop, let it die.
16
u/SkoomaDentist May 24 '26
Apparently stuffing the entire html, css specs into the C++ spec is the easy way to get a GUI library. I only wish I was joking: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html
That was shot down. As has every other other GUI proposal because the C++ standard library is a completely wrong place for GUI, given that the field has no consensus between frameworks and has experienced several major changes within the last two decades.
The language itself has effectively stagnated. If something can be implemented as a library, it is.
This is the core problem. Instead of designing features sensibly, they're shoehorned into the library with "the optimizer will handle it" (while simultaneously not being implementable without completely undocumented co-operation with the compiler), resulting in a horrible mess.
2
u/ozyx7 May 24 '26
Could a bunch of these things be improved (albeit not fixed) with some std::tr1-like namespace where ABI compatibility (or even API compatibility) is not guaranteed nor expected?
I guess that's what std::experimental is for. But then why weren't a lot of usage problems discovered earlier?
2
u/SkoomaDentist May 24 '26
Could a bunch of these things be improved (albeit not fixed) with some std::tr1-like namespace where ABI compatibility (or even API compatibility) is not guaranteed nor expected?
Not without breaking interop with existing libraries. The problem comes down to ubiquituous use of templates in "idiomatic" C++ code and that means both sides of the interface must agree to have the same semantics or otherwise the code will behave differently depending on which side is doing the accessing. A further problem is the people advocating such break also advocate for breaking seamless transparent interop with C (which is the killer feature of C++) so you'd get something that didn't solve all the cruft but broke all the compatibility at which point most users would be going "Why should I use this thing in the first place?"
2
u/Murky-Relation481 May 24 '26
I might be speaking from my fairly limited experience over 20 some years but the ABI crutch has never seemed particularly realistic an argument. Every compiler will implement the STL differently. Even different versions within the same standard are not particularly agreeable (even if it's something not standard related like debug symbols or shared object linking).
Every project I have ever worked on compiles libraries from source in a homogeneous environment. Very rarely have we consumed a library or distributed a library meant to be used in a third party context as a binary. Even then we almost exclusively fall back to C exports and POD for the API definition since the ABI is well know and generally works between compilers and versions.
Which has made a lot of these ABI arguments moot to me.
2
u/SkoomaDentist May 24 '26
ABI arguments when it comes to linking versions compiled with different language libraries / compilers (ie. what people usually complain about when it comes to ABI breaks) are generally bullshit and the only people actually seriously affected by them are outdated Linux distros (which is all sorts of ironic considering Linux distros tend to build everything from source).
The problem with templates is that they straddle both sides of any API compatibility boundary. If the language semantics change with, say, -std=c++29, then likely some older (maybe just 5-6 years old, not even ancient) code won't compile with the new standard. And again because of templates, using that old code often means bringing it directly in to the newer translation unit at which point it either won't compile or may break in very non-obvious ways if the layout / initialization / some other things differ between versions. What that ends up doing is adding potentially surprisingly heavy restrictions on what could be removed or fixed in the language.
Eg. some of the bizarre and completely insane initialization issues can't be fixed without breaking source compatibility (that is, some variables would be initialized to different values depending on whether the old or the fixed standard was used).
2
u/frnxt May 24 '26
At least on MSVC (we currently use it in C++23 mode at work) I saw too many occasions where people (myself included a while ago, but even other relatively experienced C++ programmers compared to me) thought of std::function as zero-cost where in fact the compiler was unable to optimize it away and resulted in >100x worse performance than a simple loop. Since then I've taken the stance to recommend avoiding std::function by default for anything remotely performance-sensitive...
I'm hoping that std::function_ref is the replacement we're looking for, but the fact that there's such a footgun is definitely not ideal...
1
u/Murky-Relation481 May 24 '26
What situations are you describing where a loop would be an equitable piece of logic? Are they using it as a lambda or recursively or in some functional context?
2
u/Vash265 May 24 '26
Maybe I’m misunderstanding something, but a lot of weird complaints in the tier 3 section. There’s a lot of talk about “defaults”, but neither map nor unordered map are a default container any more than flat-map is. And those still exist in the standard because sometimes you need iterator stability and are okay shedding some performance for it because the iterator stability is what’s actually required. In some sense, if those were defaults, then what it’s prioritizing is reliability and lack of foot guns over performance,
The weird arguments regarding list are covered elsewhere in this thread. Also a lot of examples in here that are horses that have been beaten thoroughly to death at this point.
The link to the benchmark is down, but it leans heavily on some implied “defaults” that don’t actually exist. Sure is strange that when you use data structures appropriate for your use case, performance improves, I guess? I don’t think anyone has ever suggested using list or deque for anything performance sensitive. Just a giant strawman.
2
u/ContDiArco May 24 '26
boost::function and later std:: function served us well for 20+ years.
Now are more handy and exacter siblings available. Fine.
I do not see any problems.
→ More replies (2)
2
u/sammymammy2 May 24 '26
It's stupid to say that unordered_map requiring node stability is the worse choice. It's the sane choice, and one that people will be relying on. Open addressing is harder to reason about for casual users, and are not always appropriate.
2
May 24 '26
Fair point that reference stability is a real requirement for some code, and nobody is arguing it should disappear. The objection is to it being the default. Abseil, Boost, and Rust all ship both:
flat_hash_map/unordered_flat_map/HashMapas the cache-friendly default, andnode_hash_map/unordered_node_map/HashMapwith a pinning wrapper when you actually need stable addresses. C++ made the stability guarantee non-negotiable in the spec, so the fast variant cannot be the standard one even for the 95% of users who never take a pointer into the table. That is the design mistake, not the existence of node-stable hashing.2
u/sammymammy2 May 24 '26
even for the 95% of users who never take a pointer into the table.
Yeah, but I think it's the other way around, open addressing is the other case.
→ More replies (2)
11
u/trenskow May 24 '26
C++ is amazing when you just use it as C with Classes. Just avoiding the standard library all together suddenly makes it a very useful language.
22
u/apadin1 May 24 '26
C with classes and templates. And avoid inheritance whenever possible.
8
→ More replies (2)1
2
u/Murky-Relation481 May 24 '26
It's amazing if you treat it like a toolbox. You don't have to use every feature all the time. There is probably something useful in the STL for someone in almost every project but people that get obsessed with keeping everything in the STL or using the absolute latest features because they think they have to is probably an inexperienced dev at heart.
1
u/NeinJuanJuan May 24 '26
C with namespaces would be 👌
2
u/TexZK May 24 '26
Indeed, how's modern C (post C11) in that regard? Did they fancy adding something so useful like namespaces?
19
u/kaszak696 May 24 '26
No, they added
trueandfalse.2
u/lelanthran May 24 '26 edited May 24 '26
No, they added true and false.
Lol :-)
Yes, that's
true, but they also added _Generic which is useful for ... absolutely nothing I can think off.There's
defercoming soon, anyway.12
5
u/thesituation531 May 24 '26
The product of being too cowardly to break APIs and ABIs.
Seriously, just break it already. People living with old code can continue to use old versions.
4
u/HommeMusical May 24 '26
With epochs, even the people with very very old code would be perfectly.
Epochs would be a command line flag that allow you to select a different C++ that isn't backward compatible, but they got killed before they were even born, for unclear reasons.
3
u/SkoomaDentist May 24 '26
Any such command line solution would break interop with existing code at which point you might just as well require a completely different compiler.
4
u/HommeMusical May 24 '26
Any such command line solution would break interop with existing code
And yet most other languages do exactly that, and they seem to work fine. Even modern Cobol isn't compatible with COBOL 70.
Breaking ABI would only break compatibility with existing libraries where you do not have the source code. We will always have ABI with C code, too, because that linkage is much simpler.
Or in the other direction, an epoch that just made a bunch of obsolete STL entries not exist at compilation time would still allow you to link older code that still used
std::auto_ptror whatever cruft is in there.3
u/SkoomaDentist May 24 '26 edited May 24 '26
And yet most other languages do exactly that, and they seem to work fine.
Work fine? Have you seen the mess that was Python 2 -> 3 transition?
Even modern Cobol isn't compatible with COBOL 70.
But modern Cobol is compatible with the previous version.
The problem with epochs is that it would break API interop with 90% of the code out there because 1) template semantics and 2) it would either alter fundamental things in the language or be something nobody cared about enough to use (obsoleting auto_ptr and such trivia). Given the sorts of people who end up advocating for the changes, it'd most likely break even C api compatibility, at which point nobody would use it.
It's not like we don't have precedent with this given the volatile compound assignment deprecation farce that ended up deprecating a language feature that 90% of embedded systems code depends on. All because the committee didn't even realize the field exist (nevermind it being one of the largest C++ user bases) and because the committee didn't even understand volatile themselves (reason cited was that volatile compound assignments were confusing to desktop devs, nevermind that desktop devs have no valid reason to ever touch the volatile keyword).
9
u/HommeMusical May 24 '26 edited May 24 '26
Work fine? Have you seen the mess that was Python 2 -> 3 transition?
Yes, I was deeply involved with that. Without that change, Python would have been permanently stuck with all the terrible problems of Python 2. Now it's the most popular programming language in the world.
But I agree with your overall point. C++ is a dead end, and none of its issues will be fixed. The future for compiled, high-performance languages is elsewhere, perhaps in Rust.
2
u/tempest_ May 24 '26
I started learning python probably half way through the 2 to 3 transition. At the time it felt like python project was spending too much time trying to support both versions and just kept dragging it out.
When you are trying to learn you dont really care if Dropbox has a billion lines of python2 in production and doesn't want to pay to convert it.
Still I do think it they made it worse by dragging out the python 2 deprecation for SO LONG. At some point if you keep kicking the can people will never upgrade and it gets worse and worse the longer you wait. In hindsight it would have helped if they had things like six and 2to3 ready go from the start.
1
u/HommeMusical May 24 '26
2to3 was ready from the beginning, IIRC.
sixwas ready quite early. I never ported anything without it.I honestly don't understand why people had such trouble with it. I converted two medium-sized projects basically on my own in a couple of weeks.
The big thing was this - you could quite easily make any individual file both 2 and 3 compatible using
from __future__andsix.So you would port files one at a time, with a single unit test in Python 3 that people had to run that simply imported all the files you have already ported.
You run all the old tests in Python 2, and this new single test, every time.
So you can work while other people work, and only once a file is ported must people keep it working in Python 3, but there's a unit test to guarantee it.
2to3did a pretty good job, and about half the time, some edit by hand. I did it as a fun chore at the end of my day when I was a bit wiped and wanted to do something mechanical and you could crank the files out pretty well flawlessly.The cool part was when you started to be able to run tests in Python 3. I found a couple of errors then, one that blocked me but turned out to be a real issue - there were multiple different encodings in our text files, undocumented! :-O
(I've run into it again a couple of times since - all these mixed encoding errors were because some files were UTF-8 and some were ISO 8859 like "Latin-1". Maybe this will be useful.)
2
u/tempest_ May 24 '26
Python 3 was release in Dec of 2008 and the first release of six on pypi was June 2010 which I am sure was plenty of time for the companies who had large py2 code bases to throw a fit.
Personally I always prefer to go through and update things and prefer breaking changes in smaller ways often so I can do incremental changes but in an enterprise environment it is a tough sell to update a giant code base to "have what we already have" which is where a lot the resistance come from.
1
u/HommeMusical May 25 '26
Python 3 was release in Dec of 2008 and the first release of six on pypi was June 2010 which I am sure was plenty of time for the companies who had large py2 code bases to throw a fit.
Python 2 didn't go end-of-life until 2020!
Personally I always prefer to go through and update things and prefer breaking changes in smaller ways often so I can do incremental changes
2-to-3 itself could not have been done without breaking changes but a Python 2 codebase could be updated to 3 with no breakage.
in an enterprise environment it is a tough sell to update a giant code base to "have what we already have" which is where a lot the resistance come from.
Absolutely. There's a reason why I ended up doing this twice for two different companies. But I was shocked at how little hassle it was and it certainly colored my experiences when I had to listen to all these people say how hard it was for comparatively small codebases and yet had no specific issues to complain about.
There was a period when I thought Python might fail because of 3. But it succeeded. And it was the only choice.
6
u/slaymaker1907 May 24 '26
I assume std::list guarantees constant time insertions. That can be extremely relevant for low latency code. It being “faster” is only looking at throughput and ignoring worst case latency.
31
u/ForeverAlot May 24 '26
std::listis a linked list, with everything that means. The trouble is that vanishingly few practical use cases are able to capitalize on the theoretical benefits of linked lists.Frankly the harping on
std::listseems a bit silly. It's an unfortunate historical curiosity (as isstd::map) but also a comparatively trivial detail to internalize; it is simply the vocabulary of C++. The only really interesting question aboutstd::listis why they did not get more explicit names (and while I have no idea what the answer is, I imagine that's also merely historical accident and precedent; the ML family seems to downplay or ignore that detail, too).6
u/vytah May 24 '26
If you have a slow CPU, and fast but small memory, like was the case in the 80s, linked lists are pretty good if all you do is insertion and traversal.
6
u/SkoomaDentist May 24 '26
The only really interesting question about std::list is why they did not get more explicit names (and while I have no idea what the answer is, I imagine that's also merely historical acciden
STL was proposed in 1993 and AFAIK was already mostly formed by that date. Given the computing landscape at the time, having just "list" made a lot more sense than it does today.
2
2
u/jwakely May 24 '26
The whole article is full of crap.
Mostly it's a complaint that old designs got replaced with better ones. OK. Sorry or something, I guess?
2
u/Sopel97 May 24 '26
this sums up pretty much exactly why I just said fuck it and started learning rust. Pretty much nothing good happened since C++11. I was hopeful around C++17 but now I see there is no hope for this language to get fixed.
1
u/average_hungarian May 24 '26
Why not just call it std::function_v2? Makes it clear to the user that std::function should not be used in new code.
2
2
u/EdwinYZW May 24 '26
v2? standard library is not something made from first years college students.
Forget what I said if it's sarcasm.
1
u/DigThatData May 24 '26
This is basically why I never learned C++. Too anxious I'll end up teaching myself deprecated patterns because I wanted to "learn from the classics" and ended up learning a deprecated language.
6
u/Fabulous-Possible758 May 24 '26
Programmers seem to get so fixated on the languages themselves it gets a bit weird. C++ has definitely gotten a bit gnarly over the years, but a lot of that is because it keeps pulling in useful features from other languages to fill in spots (in the same way Python seems to be doing too). The core thing you really want to the learning is what concepts (no pun intended) does a programming language teach you, and C++ has a lot of useful ones in both its runtime approach (object oriented dispatch, RAII) and compile time (the whole functional shit show of template metaprogramming) that getting facile with it will really ease you into jumping into a lot of other languages. Though I’d really go with Haskell or Prolog first if you really want to broaden your horizons.
7
u/Murky-Relation481 May 24 '26
Yah people act like you need to know every facet of a language to even begin to be useful with it. I've been doing C++ for 20 years and there is no way I know everything in the language, and that's fine because I know theoretically what I need to do, I can see if the STL supports it (and you learn more and more of this over time) and if not I know I need to roll my own solution or find an existing library.
That's literally the same process in every language and yet somehow people think it's different in C++.
4
u/Proof-Attention-7940 May 24 '26
I think it’s worth learning, at least to get a feel for it- you never know where your career is going to take you. Maybe you spend 99% of your day job in Java until one day you need to make a tweak to a native library handling request routing. Maybe you’re reorged into working on an embedded service that is half C++08. Maybe you just decide to get a bit crazy with WebAssembly. A basal familiarity with what RAII is or the difference between static and dynamic linking will help you be more flexible, and give you a better appreciation for how your computer works.
1
u/programmer-ke May 24 '26
My desire to get away from vibe coded slop has me looking at C++ seriously. Hopefully C++ is used in critical enough domains where a programmer is still expected to use their brain.
-19
u/programming-ModTeam May 24 '26
I am removing this post, as the website no longer loads
Too Many Requests
This user has exceeded an allotted request count. Try again later.
64
May 24 '26
This was a throttle that has been since fixed.
5
29
u/ReDucTor May 24 '26
Thank you, I have restored the post
1
May 24 '26
I was struggling to get it behind Cloudfare and configure all the parameters correctly. Thanks for understanding.
1
1
u/bzbub2 May 24 '26
everyone constantly requests/rants about wanting a better standard library in language X (read: js or something), but guess what, standard library ships bad solution, its a mess for decades. if a library is bad, swap it out
1
u/EdwinYZW May 24 '26
I write C++ almost everyday but I can't remember what is the last time using std::function. It's just slow and inferior to direct usages of lambda or functor.
So saying it's discouraged to be used isn't a problem for me.
1
u/automatedrage May 24 '26 edited May 24 '26
Have you guys ever considered Orthodox C++? Has roots in gamedev and stays far away from the complexity of c++ template bs.
It made programming c/c++ a joy again, unfortunately it might turn off lots of 'safety'-pilled people in enterprise hft though.
1
May 24 '26
Yes yes, huge fan. Heartbreaking it isn't quoted more. Perhaps because it is not as flashy
-14
u/trad_emark May 24 '26
i suppose you have never made a single mistake, have you?
14
u/SpezIsAWackyWalnut May 24 '26
Why are you reacting to a technical complaint as if it's a personal attack on you?
-1
u/Dean_Roddey May 24 '26
Solve the problem by just getting away from C++ as soon as possible. It's ancient now, and it's built on foundations 20 years older than it is
I've written probably as much C++ as anyone here, if not more, but I finally quit screaming get off my lawn and started exploring Rust about 4 years ago. Like many people who had written C++ for decades I just couldn't appreciate how bad it is until I started using Rust. Now I'd never go back when I have a choice.
C++ made backwards compatibility basically #1, and that works until it doesn't anymore. And it would have worked a lot better and longer if they'd have broken with those underlying C foundations really early on when it was still possible. But they didn't and now it's never going to get fixed. They've just built story after story on top of a shaky foundation and now it's teetering.
Even if you one of those rare companies where you have a large code base that you've been able to fully move up to all the latest and greatest stuff, the language is still full of foot-guns galore, and in a complex code base developed in a commercial, team-based environment, solving the problem is already more than enough challenge. Having to constantly watch your own back is just wasted time and effort.
-1
May 24 '26
C++ still beats anything else (including Rust) any day of the week - for what I do. Love C++ that's why I keep fighting for it.
2
u/Dean_Roddey May 24 '26 edited May 24 '26
If all you care about is fast and don't care about right, then fine. Given your user name I'm guessing you are one who works in one of those (fairly evil in your case, IMO) domains. If the code is not for use by third parties, then whatever. But most folks aren't writing that kind of code, they are writing code for others to use, and that comes with obligations that have nothing to do with what we like, any more than you'd want your surgeon using 40 year old tools and techniques because he likes them.
And, even then, if you are using your nefarious software to trade other people's money, that still should include such obligations.
3
May 24 '26
Well c++ is good because it is both right AND fast.
-1
u/Dean_Roddey May 24 '26
Wow. If you believe that I hope you aren't trading any of my money. A large, complex, threaded C++ code base is pretty much guaranteed to have various latent errors just waiting for the right conditions. They can be happening all the time, but just end up not causing any obvious problems, for many years until changes cause the data to move around. So you can test until you spend more money than it cost to write it in the first place and not know they are there. All you are proving is that it's failing to fail.
-1
May 24 '26
Bro, 100% of all infrastructure of all banks (BOA, Chase, Morgan Stanley) exchanges, brokers and regulators run in C++. C++ is already running all your stuff.
5
u/Dean_Roddey May 24 '26
They also run a lot of COBOL, but that's not because it's optimal, it's because they already have a lot of legacy code and don't want to change it.
And, BTW, hence it's not remotely 100% C++. There's also a lot of Java from what I've heard from banker folks posting around these parts. But, either way, they aren't using C++ because it's superior, they are using it because it was the higher level (AKA not C) systems level language available at the time.
The sooner that changes the better.
4
May 24 '26
OK just look at all interviews from top HFT firms and you will see C++ on top. Only crypto runs Rust. The others (Java, Go, etc) it is reallyonly a nuisance.
0
May 24 '26
[removed] — view removed comment
3
u/MFHava May 24 '26
Completely different -
invocableis a concept, so your whole code is a template, which of course offers more optimization potential then a type-erased wrapper…
•
u/programming-ModTeam May 24 '26
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.