C++ has to be approached as a grab bag of useful parts, not a coherent whole. It's somewhat akin to Python if Python modules were C++ language features. It's said that nobody knows all of C++, even its creators.

Do you know C? Everything that works in C works in C++, modulo a few minor syntactic changes (void* doesn't implicitly convert). You can get acquainted to C++ features on an as-needed basis. Other people will surely disagree with me on this.

With pointer types in particular, I'd say use C-style pointers long enough to know how frustrating they are but also how they work. Then you'll know what unique_ptr and shared_ptr are doing to help you. (And those are the only two you need 99% if the time. weak_ptr is a spin-off of shared_ptr that you'll know if you need it. observer_ptr is just stupid ivory-tower stuff.)

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

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++.

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.

"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."

You can of course use Python. But we are talking about languages with different applications. You want fast development hand have no expectations on speed? Use Python! You want to control your computer to get maximum performance with a safe type system? Use C++!

Since you are already talking about pointers: In Python you are not even given the chance to do all the stuff you can do in C++. You have to rely on garbage collection (and "del"). That is an entirely different thing than C++ where you exactly control how long your objects should live.

For the pointers (order I would suggest): 1) No pointers, use references whenever possible 2) Use std::unique_ptr 3) Use std::shared_ptr

You can also try to use shared_ptr all the time if it makes your transition from Python more easy. It is not optimal, but it may get you started.

And do not start wrapping your head around rvalue references right from the beginning. This is a very special topic, which you can ignore as a beginner.

I studies for some descent while with the objective of using unreal engine, then i found out everyone was just using blue prints so not even them liked CPP

> which pointer should I use?

The answer is almost always: no pointer

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.

> 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.