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

Rethinking C++: Architecture, Concepts, and Responsibility

blogs.embarcadero.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#61

Post by jandrewrogers »

jnwatson wrote: post #51
jandrewrogers wrote: post #12

Earlier quoted context omitted.

C++20 inverts the traditional relationship between the core language and metaprogramming, which arguably makes it new language in some ways. Instead of being a quirky afterthought, it has become the preferred way to interact with code. There is a point of friction in that the standard library doesn’t (and can’t) fully reflect this change. Metaprogramming style in C++20 only has a loose relationship to previous versio…

If you're going to go through the effort of learning a new language, it makes sense to consider another language altogether, one without 30 years of accumulated cruft.

An advantage is that if you already know the older language then you don’t have to learn the new idioms up front to use it. You can take your time and still be productive. It isn’t why I would use it but it is a valid reason.

I have used many languages other than C++20 in production for the kind of software I write. I don’t have any legacy code to worry about and rarely use the standard library. The main thing that still makes it an excellent default choice, despite the fact that I dislike many things about the language, is that nothing else can match the combination of performance and expressiveness yet. Languages that can match the performance still require much more code, sometimes inelegant, to achieve an identical outcome. The metaprogramming ergonomics of C++20 are really good and allow you to avoid writing a lot of code, which is a major benefit.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#62

Post by simonask »

wavemode wrote: post #47
simonask wrote: post #29

From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that th…

> decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011? If you've worked on a project built entirely on the technologies and principles of modern C++, and found that it caused your software to be low-quality, then by…

> How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011?

Please read the sentence you're quoting again.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#63

Post by RobRivera »

simonask wrote: post #29

From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that th…

Honestly, I find myself reassessing my stake in the c++ ecosystem on occasion when I discover a new way I broke it. Often my post mortem reveals, yes, skill issue, and yes I agree, many of my paradigms and patterns orient around limiting the impact crater.

Honestly tho, I keep the tool in my belt because I believe it is still the best for what I use it for: low latency financial applications and game engines.

If I find some time to migrate from c++ to a different language I may for certain games, but thats a future bridge to cross.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#64

Post by on_the_train »

recursivecaveat wrote: post #45

It's okay to admit when C++ doesn't have a feature. std::variant is an approximation of sum type support. It's ergonomics are an absolute travesty as a result, any errors you get are going to be 5 pages of template gunk, and I'm sure that using it pervasively is terrible for compile times. It has been possible to construct a type safe unit library as demonstrated in the article for forever. I've never seen anyone use…

> If you call .error() and you're wrong you get undefined behaviour. This was added in C++23.

And it was fixed in c++26

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#65

Post by wavemode »

simonask wrote: post #62
wavemode wrote: post #47

Earlier quoted context omitted.

> decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011? If you've worked on a project built entirely on the technologies and principles of modern C++, and found that it caused your software to be low-quality, then by…

> How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011? Please read the sentence you're quoting again.

I've read it. If you have a response then say what you're trying to say.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#66

Post by gwbas1c »

instig007 wrote: post #34
gwbas1c wrote: post #31

> Library vendors must have the courage to create a new generation of libraries—libraries that consistently use concepts, typelists, ranges, and compile‑time mechanisms. Compiler vendors, in turn, are responsible for continuing this development and fully unlocking the new language means. > But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because th…

> Once you get to that point, you might as well create and learn a different language. Nope, it's still incredibly valuable to be able to c++14 and c++26 two different translation units and then later link them together (all without leaving the familiar toolchains and ecosystems). That's how big legacy projects can evolve towards better safety incrementally.

Many languages have ways to call into old code. C++ allows calling C; so does Objective C.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#67

Post by fsloth »

jebarker wrote: post #24
jandrewrogers wrote: post #12

Earlier quoted context omitted.

C++20 inverts the traditional relationship between the core language and metaprogramming, which arguably makes it new language in some ways. Instead of being a quirky afterthought, it has become the preferred way to interact with code. There is a point of friction in that the standard library doesn’t (and can’t) fully reflect this change. Metaprogramming style in C++20 only has a loose relationship to previous versio…

As someone that has only dabbled in C++ over the past 10 years or so, it feels like each new release has this messaging of “you have to think of it as a totally new language”. It makes C++ very unapproachable.

C++ can be written as the optimal industrial language it is. Simple core concepts year after year. Minimal adaptation.

The key thing to understand you are still using C with sugar on top. So you need to understand how the language concepts map to the hardware concepts. So it’s much more relevant to understand pointer arithmetic, the difference between stack and heap allocations and so on, rather what the most recent language standard changes.

You can write the same type of C++ for decades. It’s not going to stop compiling. As long as it compiles on your language standard (C++17 is fine I think unless you miss something specific) you are off to the races. And you can write C++17 for the next two decades if you want.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#68

Post by dustfinger »

ActorNightly wrote: post #60
dustfinger wrote: post #39

Despite all the critisism, C++ has been my favorite language for 20+ years. Nowadays I code 99% of the time in python and previously TypeScript, but all my personal for fun projects are in C++. I just enjoy coding in it so much more. I know I will get some heat for this, but I would love to live in an idealistic world where computers were still for hackers and it was all just about fun not profit. I was so inspired b…

> but I would love to live in an idealistic world where computers were still for hackers This never changed. In the past, hacking was exploiting human errors in writing faulty code. These days, its pretty much the same thing except the faulty code isn't things like buffer overflows due to no bounds checking, but more higher level faulty software with things like password reuse, no 2 factor authentication, and so on.

While that is partly what I meant, my notion was really about being creative, inventive and having a lot of fun hacking code or hardware without it being about work. I really meant these notions of hacking:

- https://stallman.org/articles/on-hacking.html

- https://stallman.org/articles/happy-hacking.html

- http://www.catb.org/~esr/faqs/hacker-howto.html

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#69

Post by simonask »

wavemode wrote: post #65
simonask wrote: post #62

Earlier quoted context omitted.

> How can "decades of experience" show the deficiencies of Modern C++, which was invented in 2011? Please read the sentence you're quoting again.

I've read it. If you have a response then say what you're trying to say.

My criticism is not of any particular feature in C++ (though there is much to both hate and love about it), but of a particular approach to software engineering that the language design leans into, and which even the newest iterations of the language do nothing to alleviate, and in many many cases even reinforce.

The easiest path in C++ is almost always the dangerous path. (The classic example is operator[] versus at().) With every tiny feature of the language, things we take fully for granted in every other language, there is a host of caveats, gotchas, footguns, and trap doors.

This is as serious risk as a project and its team grows, because the accumulated sum of accidental complexity grows exponentially.

It’s possible to manage this risk, but it is also expensive, and every modern-ish competitor to C++ allows fewer people to deliver better software quicker.

It’s not a good choice for almost anything that doesn’t specifically require C++ for its own sake.

Re: Rethinking C++: Architecture, Concepts, and Responsibility

#70

Post by germandiago »

simonask wrote: post #29

From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that th…

It is true that it will never be Rust-safe level bit there is ongoing work: stl library hardening is in for C++26, there are some temporaries dangling that has been removed (range for lofetime extension and forbid conversion snd binding to temporary), there is a form of implicit contracts on the way (this means that even regular code can be compiled wirh implicit bounds checking, including arrays) and there is sn ongoing effort to remove all forms of UB.

So I agree it has its quirks but if the defaults keep changing and improving it keeps evolving into a safer by default thing compared to before.

No, I do not mean into you must be super-skillfull anymore: I mean that with all of that in, things are much safer by default.

Things keep improving a bit slower than we would like (this is design by committee) but steadily.

Post reply on HN