Let's not vague post on HN. What's the problem with the above?
replyThe problem is the code unconditionally dereferences the pointer, which would be UB if it was a null pointer. This means it is legal to optimize out any code paths that rely on this, even if they occur earlier in program order.
replyThis is a very "Dr Dr it hurts when I do this" "Don't do that" one it must be said.
replyI'm sorry, but what exactly is the problem with the code? I've been staring at it for quite a while now and still don't see what is counterintuitive about it.
replyDepends on where you're coming from, but some people would expect it to enforce that the pointer is non-null, then proceed. Which would actually give you a guaranteed crash in case it is null. But that's not what it does in C++, and I could see it not being entirely obvious.
replyAssert doesn't work like that in any language.
replyIt does in Rust: assert is always enabled, whereas the debug-only version is called debug_assert.
replyBut yes, “assert” in most languages is debug-only.
There's nothing wrong with it. It does exactly what you think it does when passed null.
replydeleted
reply