Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Two Factions of C++ (2024)

herecomesthemoon.net

Post reply on HN
Print view View original

51–60 of 89 posts

Re: The Two Factions of C++ (2024)

#51

Post by pornel »

tonyedgecombe wrote: post #29

> “We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.” But the major players do seem to be happy to replace their C++ code wi…

> But the major players do seem to be happy to replace their C++ code with Rust.

Because incremental improvements don't provide enough value. A stable C++ codebase is best left untouched. It's not worth to rewrite C++ into C++++ to get a couple of features that are flawed retrofits backported from modern languages. In the end you still have C++.

Re: The Two Factions of C++ (2024)

#52

Post by seethishat »

cherryteastain wrote: post #6

> Google supposedly significantly lowered its participation in the C++ development process, and instead started to work on their own C++ successor language. Did they decide to keep things as is or rewrite in Rust with LLM assistance in the couple years since this article? Carbon seems to have gone nowhere.

Go is good enough for many tasks. Google wrote that as a replacement for C++ too. I guess Carbon is intended to be more for systems programming? Go had that intent initially, but soon realized that's not a good fit.

Re: The Two Factions of C++ (2024)

#53

Post by usrnm »

bluGill wrote: post #33
usrnm wrote: post #11

Earlier quoted context omitted.

> it was also a mess of intricate object ownership Not much has changed, though, it still is. Just with a lot more bells and whistles around it

Much has changed for me since I used smart pointers where possible - which is the vast majority of the time. I am currently telling somebody you can't change a QString to a C string even though the C string probably won't overflow in that use. I have changed.

Smart pointers existed long before C++11. std::auto_ptr was a mistake, but it wasn't the only option

Re: The Two Factions of C++ (2024)

#54

Post by neutronicus »

HappMacDonald wrote: post #40
YuechenLi wrote: post #36

In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…

> There is a good language buried underneath C++ somewhere Well.. "C".. though I wouldn't go so far as to call that a good language, either.

C++ at least rescues you from defining a million callbacks with a void* context argument that you then cast into whatever you know it actually is

Re: The Two Factions of C++ (2024)

#55

Post by locknitpicker »

YuechenLi wrote: post #36

In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…

> In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#.

I don't think that professional developers go around mindlessly starting projects without evaluating their choices. The truth of the matter is that the whole industry has been picking C++ over alternatives for ages, to the point where C++ managed to get one of the most popular languages devised. Why do you think that happened?

> I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch (...)

That says more about your competence than anything. I mean, CMake works so well that companies such as Jetbrains developed their C++ IDEs around it. But somehow you seem to struggle where everyone just dash towards coding. Why is that?

Re: The Two Factions of C++ (2024)

#56

Post by abbefaria27 »

To be fair to the committee, upgrading C++ compilers is already a chore, even with the changes as small as they are. Would you rather spend time updating your lambdas because they changed how capture works (a real breakage not long ago), or doing something of actual value? The only reason we finally updated from Python 2.7 to 3 was that the OS vendors dropped it, but it was effectively a waste of time.

That aside, I don’t understand why ABI breakage is a big deal. There’s probably a good reason, but ABIs are already so fragile, you can’t mix and match different compiler versions anyway, or even the same compiler with different flags. Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same?

The C++ committee should really stop adding esoteric features for library writers and focus on stuff for normies. Tooling is one as the article says, or how about finally getting Networking TS? This is probably the only mainstream language left that doesn’t have even basic networking support.

Re: The Two Factions of C++ (2024)

#57

Post by randusername »

Either the shop will be C++-14 for all time or they will do whatever it takes to use the latest and greatest compilers and language features.

I don't see why breaking changes is such a major concern.

Unless the aggrieved party is the compiler maintainers, I guess.

Re: The Two Factions of C++ (2024)

#58

Post by bluGill »

usrnm wrote: post #53
bluGill wrote: post #33

Earlier quoted context omitted.

Much has changed for me since I used smart pointers where possible - which is the vast majority of the time. I am currently telling somebody you can't change a QString to a C string even though the C string probably won't overflow in that use. I have changed.

Smart pointers existed long before C++11. std::auto_ptr was a mistake, but it wasn't the only option

Smart pointers somewhat existed. Without move they were vastly less powerful. (You could have a generic shared pointer without move, but unique pointer has useful properties that you cannot get without move) Non-generic smart pointers - RAII - was very common but that was implemented separately for everything. Having to figure out how to deal with copy was a problem (though many times you disabled it and then passed a reference or a raw pointer to the object - a poor mans move which sometimes was good enough but often was annoying).

More importantly, before C++11 every library I worked with had their own incompatible way of managing memory. None of them used smart pointers in the API, it was always raw pointers (or references where possible but often not possible) and their own documented ownership rules. Any single library was simple enough to follow the rules (hint we got it wrong often), but the combination was very complex and sometimes impossible to combine the two different rules.

C++11 changed how most people manage memory. You could get the same effect without, but it was both more complex, and nobody agreed on the same rules.

Re: The Two Factions of C++ (2024)

#59

Post by jcranmer »

logicchains wrote: post #14
gignico wrote: post #3

Earlier quoted context omitted.

I understand the issue about the ever-moving target etc., but almost fifteen years later do you really believe C++98 is better than C++11 without move semantics and decent smart pointers? I remember working with Qt5 and C++98 and yes, it was productive, but it was also a mess of intricate object ownership. I'm critical about some choices made with C++20 and after, like the mess that modules are, and the too-little-to…

>C++26 is also a joke imho. C++26 will allow billions of lines of pointless serialization boilerplate to finally be deleted, adding the basic reflection functionality that most other languages have had for decades.

I'm not sure C++26 reflection is sufficiently well-baked to actually allow it to be used for serialization boilerplate in codebases. What matters is not what the standard says, but what the compilers implement, and the compiler implementers I know have been kvetching about how problematic reflection is, to the point that it may never be turned on by default.

Re: The Two Factions of C++ (2024)

#60

Post by YuechenLi »

throwaway2037 wrote: post #47
YuechenLi wrote: post #36

In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#. I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad, because I swear I spent 2 days trying to setup CMake to get Skyrim modding setup, and in the end, I had to tap ou…

> involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad In 2026, CMake is the standard build tool, and Google Test is usually a safe choice. There are many example projects on GitHub to learn how to use them.

I think you misunderstood me. I did use them at first, but it took so much effort for me to set them up and config them for that particular application (Code only Skyrim modding) where I pretty much spent an entire day debugging and diagnosing crashes in CMakeLists.txt with the only info being random forum posts and Youtube videos on the subject without having written a single line of C++ that I decided to build my own instead.
Post reply on HN