Hacker News Reader

Comment by Routine8502 | Hacker News Reader

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!

View on HN

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

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

Made me LOL

Knowing the story behind a decision like that is worth a thousand spec clauses.

When the language got operator overloading there was the question of how to convert the arguments from the operator itself to its implementation. You wanted to write a+b, not &a+&b but most versions of operator+ were going to want const pointers for efficiency. One option was to make the & implicit, another was to introduce a type of argument that didn't need & but acted like a pointer. So references were born.

I ignore people who advise to use references when something can't be null. A null reference is UB just like a null pointer, it just shifts where the UB is, but the compiler is likely to produce the same code either way and the program is just as likely to crash. Instead, I use pointers to make it obvious that something is a pointer, and references when it should be invisible, just like with operator overloading.

The source of the UB is dereferncing a null pointer. I don't think it's possible to obtain a null reference otherwise. I, on the other hand, ignore people who advise against using references for parameters that can't be nullable. Particularly const references, which provide potentially massive performance improvements, and are a core idiom in C++.

> Particularly const references, which provide potentially massive performance improvements

My understanding was that const references don't provide that much in the way of optimization opportunities (if any?) due to aliasing and the existence of const_cast.

It's not about that, it's about avoiding copying to a function parameter. If you want a function that adds a bunch of integers, you should write it as "int sum(vector<int> const&)" rather than "int sum(vector<int>)" because the latter will copy the whole array of numbers just to sum them and delete the copy, when you could have summed the original array with no downside. Arguably it should be span<int> though now that exists.

If you just want to avoid a copy without adding a null state then it's the reference bit that makes all the difference. Whether that reference is a const reference or not does not matter for optimization, I think.

If you make it a non-const reference the compiler won't let you pass a result of another function call such as sum(get_daily_prices())

Sure, but I think that has less to do with optimizations and more to do with avoiding potential footguns. The standard could, in principle, allow temporaries to bind to non-const references (and IIRC older versions of Visual Studio did do such a thing).

And even without such a change, such a restriction is pretty easily worked around without a const reference with something like T&& temp = get_daily_prices(); sum(temp);. I don't think that'll result in different codegen than either passing a temporary to a const ref or allowing binding a temporary to a non-const ref.

Things I read recently makes me think that default target for stuff like that is a manky compiler that's half a step above macro assembler. AKA it's much faster if your compiler is dumb as rocks and usually not with actual compilers.

Somewhere you have a null and somewhere you want to call a function on it (by mistake). Whether you call it through the pointer or convert the pointer to a reference and then call it through the reference makes no difference, the program still has UB. You can't even argue that the UB occurs at a different point in the program - that makes no difference because UB is allowed to time-travel.

Didn't they say they use references when the pointer/reference should be invisible?

One of the first production C++ codebases I worked on had helpers:

  Type& GetReference(Type*);

(Type is a placeholder, it was not templated). It worked exactly how you'd fear it would, and as a result we had to chase down null dereferences of our "can't be null" references all over the codebase.

EDIT: by "exactly how you fear it would", it just did a dereference and return. It didn't check for null, didn't throw, and couldn't otherwise signal a failure.

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.

> 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

C++ is not unique in having historic spec mistakes but it has by far the most of them which are still relevant today of all languages I have used. Maybe Perl or PHP come a bit close, but I doubt it.

Perl hasn't evolved in a while but PHP is definitely full of historic mistakes, dating all the way back to the first versions using strlen as a hash for function name lookup.

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

for (ignoring do and while) and foreach loops, std::for_each, ranges for_each at the very least

...which is the same as nearly every other language? What language doesn't have that same collection of stuff?

Java: for, for-each, do-while with iterator, list.forEach(..), list.stream().forEach(..), etc...

Python?

for i in list, enumerate(), for i in range(len(list)), while loop, list comprehension as a map, generator expressions, map() function, iter(list) + next()

The only thing it seems to be missing is a for_each function, assuming you aren't doing a map() in which case then that exists.

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

It's probably nice to know WHY you might need weak_ptr.

Explanation: shared_ptr is an implementation of "reference counting". All shared_ptrs to the same object collaborate to know how many of them exist (it's just a ++ on creation of one, -- on destruction of one) and when the last one is destroyed it also destroys the object that's pointed to.

weak_ptr is like shared_ptr but doesn't add to the count. When the last shared_ptr is destroyed it destroys the object even if there are still weak_ptrs. Any weak_ptrs pointing to that object become null. I won't dive into how that's actually implemented. Obviously it costs some CPU cycles to make that happen, so you don't see shared_ptr or weak_ptr a lot in code that's written with a performance mindset. Although you're still getting 90% of the performance benefit by writing C++ instead of JS even if it's "inefficient" C++.

I agree with GP's point and add, if this isn't something you need to do, then don't even think about it. C++ is like a toolbox with a bunch of tools. I don't study all the tools before building a table, I look up how to build a table, and then see if the tools are in my toolbox. Studying the triangle screwdriver would be a waste of time and only confuse me more, unless I'm trying to drive triangle screws. Only when I need to drive a triangle screw then I can look for the triangle screwdriver.

For the same reason you need weakref in Python, to handle circular references in memory managed via reference counting GC algorithm.

https://docs.python.org/3/library/weakref.html

Anyone that thinks Python is "simple", to come back to some of the suggestions on how it is easier than C++, they really should learn the language reference, standard library, and CPython FFI manuals.

> Anyone that thinks Python is "simple", to come back to some of the suggestions on how it is easier than C++, they really should learn the language reference, standard library, and CPython FFI manuals.

Python is more "simple" in the sense that

- it is more forgiving with respect to badly written code,

- it has collected less historical baggage than C++.

Otherwise I agree.

It really isn't less forgiving, it just happens that as a dynamic language, it blows up at runtime instead of failing to compile.

Yeah, we all know how cleaning up Python has worked out, and unfortunately a few ecosystems failed to learn from it as well, e.g. Java 8 => 9, .NET Framework => Core.

The things that make C++ unforgiving is not the things that blow up at compile time. Those are trivial to deal with, comparatively, since you have the error right there. It's the things that compile, but then blow up in weird, and often unpredictable ways that make C++ unforgiving. Or to put it another way, it's the lack of undefined behavior in most situations that makes Python more forgiving.

Yes, Python may still blow up at runtime if you don't get it exactly right, but it'll blow up in very predictable ways: Off by one errors accessing arrays doesn't work some of the time, maybe, except on Tuesdays, instead you always get an IndexError. And some cases, like overflows/underflows, doesn't even blow up, instead you just get bigger/smaller numbers.

Type-hints also does a lot (but still not enough, IMO) to reduce the amount of blowing at runtime up that you might experience when working in Python. Though that obviously wont help with poorly written code, which is unlikely to have proper type hints

> The things that make C++ unforgiving is not the things that blow up at compile time. [...] It's the things that compile, but then blow up in weird, and often unpredictable ways that make C++ unforgiving.

Exactly.

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.

Agree with that. I'm a veteran user of C++, and I'm constantly finding really nice idioms in AI-generated code that I end up using myself.

One of the interesting things about C++ is that things that are language features in other languages are idioms in C++.

When they are turned into features people complain about C++ becoming too complex. So, what can you do...?

What exactly was your problem?

And was it the language itself or the libraries?

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

> You can of course use Python.

Which also has plenty of way to do the same thing.

People often mistake the easiness to write Hello World, with the real expressiveness that is available in any given language.

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

True, and that advice is useful to people coming from JVM languages. But you do often need pointers.

I'd say pointers are very rare in proper code.

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.

Maye you need a better AI. Just sayin'. My AI (Claude) doesn't make mistakes. Ok. It doesn't always think strategically, or factor well. But it certainly doesn't struggle with language mechanics.

Modern best practice for C++ is to crank the warnings to maximum, and to treat warnings as errors. You absolutely should treat linter-like warnings as an error, because they invariably are. So you know.

It’s been my experience that pair programming specifically in C++ with an LLM rather than having it write the code is a great way to stay sharp.

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

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

Maybe. Many people have tried, but only Rust has gotten anywhere close, and Rust can hardly be described as "not complex".

Reply on news.ycombinator.com