Hacker News Reader

Comment by kllrnohj | Hacker News Reader

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

View on HN

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.

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

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

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?

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

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.

Made me LOL

Reply on news.ycombinator.com