Hacker News Reader

Comment by rerdavies | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com