Hacker News Reader

Comment by masklinn | Hacker News Reader

> As far as I'm aware, if you stay within the confines of smart pointers (and don't drop down to the raw pointer it owns) you will never encounter undefined behavior.

Deref'ing an empty (e.g. moved-from) unique_ptr is still UB.

View on HN

Yeah, there's that. It would be nice if C++ did a emptiness check for you, but I guess that this wasn't in the cards…

Then you have a check on every deref, which means you incur a relatively large performance penalty for using a smart pointer. If you want stuff like this there are other languages out there.

Would it be possible to write the check so that the null test overlaps with the rest of the instructions? If the test is anyways assumed to pass, you should only get a 1-instruction overhead, right?

(That'll only work for null.)

1 instruction != 1 clock cycle. In particular that would utterly kill the usage of unique_ptr on things like small embedded processors or microcontrollers that either lack speculative execution entirely or do not have the level of branch predictor & speculative execution capabilities of a high-end x86 or ARMv8 CPU.

FWIW: in general, simpler controllers (especially those in-order ones) tend to be much more friendly to branching (exactly because they're not out-of-order). NB: I am not arguing whether unique_ptr<> should check or not: if I want checked version, I will write my own wrapper, it is not a rocket science.

While we're on "nice to haves," it would be great if there was a way to explicitly terminate the scope of objects. Then you could have an atomic move-from-and-remove-from-scope operation. Which removes any possibility of accessing the moved-from object again.

Reply on news.ycombinator.com