Remix.run Logo
▲ Routine8502 2 hours ago

As someone who spent a few weeks trying to get into C++ (pre-LLM, so maybe it's better now?) and kind of just gave up out of confusion, I really found it challenging to deal with the multiple different ways to do something. I mean, which pointer should I use? How should I iterate? I'm sure there's an answer to this, but I just found it easier to go back to python and hit up rust when I needed it.

It seems like part of the concern is that the feature needs to be shipped right the first time because it'll live forever. Perhaps allowing features to be deprecated and then removed could help?

But idk, I haven't written anything that lasted 36 years, so maybe the current approach is for the best!

▲kllrnohj 2 hours ago | parent | next [-]

Does the existence of PEP 572 not similarly result in being paralyzed and overwhelmed at the number of ways to do something being greater than 1?

C++ definitely has complexity, but I'm surprised by the two examples specifically chosen. Which pointer? C++ only has 2: unique_ptr and shared_ptr (or 2.5 if you want to include weak_ptr but that necessarily means you already chose strong_ptr first). While this might be a complicated choice if you're just comparing to Python, but it shouldn't be if you're familiar with Rust since Rust has you make the same choice.

And then "how should I iterate" is similarly the same as any other language? Either a for or a for-each loop?

There's definitely baggage from 38 years of lessons learned, to be sure, just those examples are odd choices

▲TheOtherHobbes an hour ago | parent | next [-]

You've already mentioned four pointer types which are separate to the original plain vanilla pointer concept.

https://en.cppreference.com/cpp/language/pointer

When I started C++ nearly 15 years ago this was already a huge problem. I bought some books and looked up online references and after a while I discovered that both were already out of date.

C++ is a chimera. And it hasn't improved since.

Other languages are far more stable, conceptually. New features rarely undermine or reinvent the older ones.

C++ is unique in the way it keeps modifying its own core. There is no formal deprecation or EOL process, so the language is more like an archaeological dig than a living standard.

▲kllrnohj an hour ago | parent [-]

> There is no formal deprecation or EOL process

Yes there is or we'd have been talking about std::auto_ptr as well.

> New features rarely undermine or reinvent the older ones.

Many languages have mistakes they've later tried to sweep under the rug. JavaScript arrow functions trying to convince everyone that bind(this) wasn't ever a thing, for example.

C++, for whatever reason, is consistently the only language where people are determined to always dig up the skeletons and pretend they are at all still relevant. It's not unique in having skeletons. It's not unique in having language spec mistakes that can't realistically be changed, just ammended with a newer, better alternative.

But like the saying goes, there are only two kinds of languages: the ones people complain about and the ones nobody uses

▲StilesCrisis 2 hours ago | parent | prev [-]

Don't forget * (true pointer) and & (called a reference, more honestly a pointer that can't be repointed, except with UB it can _totally_ get repointed).

▲senthil_rajasek an hour ago | parent [-]

Made me LOL

▲MathMonkeyMan 2 hours ago | parent | prev | next [-]

Features are deprecated and removed. It's uncommon but it happens when a new feature makes all use of the old feature unnecessary. Usually it's deprecated for a few versions and then removed some years later. You can always compile old code against an old standard.

C++ does have many ways to do anything. Most of that is historical, or due to features and library facilities with overlapping capabilities, or inherent to multi-paradigm programming languages.

Every C++ project is written in its own language. Its own "house flavor." This is true of all languages, but is particularly stark for a language as old, complicated, and powerful as C++.

▲rickstanley 2 hours ago | parent | prev | next [-]

I share the same sentiment and experience from trying to get into C++. I bought "A Tour of C++" (2022, Stroustrup), I read it back to back, and I thought to myself "it's not so bad, seems quite nice actually, specially the modules part"... oh boy. After 2 weeks writing a HTTP requests CLI tool I was feeling really demotivated, I gave up and went to rust, for no special reason, I just had it queued up after reading "The Rust Programming Language" book.

> pre-LLM, so maybe it's better now?

I came back to the toy tool some time later and used GLM 4.x to implement it further. I had a good experience with it and I understood the code it generated. From my experience, in general, LLM is a good mentor, if you are willing to ingest the content step by step. For me, it is no different from when I used StackOverflow (and other forums) to try and ask how a thing is done.

▲yodsanklai 2 hours ago | parent | prev | next [-]

You're very diplomatic (yet downvoted), C++ is an abomination of a language. It just puts too much accidental cognitive load on developers. I understand that

- it shines for some tasks where Rust isn't capable enough

- it's impossible to get rid of because of all the code so we may as well modernize it

- there's an active community of people who built a career of being C++ experts and have no interest to see the language disappears.

Even in the LLM era, I find it's difficult to code in C++. The language has so many corner cases that LLMs make mistakes. My experience 6 months ago was that the code written by my agent had tons of complex linter warning (exceptions, lambda leaking references, futures whatever... that I just can't avoid because the codebase mixes all of this). Whenever possible, it's probably time to either modernize it or port it to Rust, component by component, until the C++ part is small or inexistant.

▲mathisfun123 an hour ago | parent | prev [-]

> As someone who spent a few weeks trying to get into C++ and kind of just gave up out of confusion

what should be conclude from this? this is like saying you tried to become a professional trapeze artist for a couple of days. C++ is complex and deep. what did you seriously hope to accomplish in a "few weeks"?

i started writing C++ professionally 4 years ago, i.e., i write it every single day at $JOB. there are still large parts of the language i'm not familiar with.

▲zahlman 39 minutes ago | parent [-]

> what should be conclude from this? … C++ is complex and deep.

Yes, that's the point. Much of this complexity would not be necessary to achieve the same things, given the ability to redesign from scratch.