4 ms·

I don't know about you guys, but as a reader unfamiliar with their codebase, when I see return &*rhs == NULL; I think exactly what the optimizer thought:

by tines 11y ago

I don't know about you guys, but as a reader unfamiliar with their codebase, when I see return &*rhs == NULL; I think exactly what the optimizer thought: "Well, the address of an object can't ever be NULL, so this expression always evaluates to false." I don't think code that does this is "semi-legit"; it's completely counter-intuitive to abuse the expected semantics of unary `operator*` that way, even if the compiler did have no problem with it. You can't expect a new member of the team to read this and not have fire alarms go off in their head. As a side note, I also think that this optimization would be done by any compiler capable of basic pointer analysis. This isn't really GCC being out-of-the-ordinary "super-smart."

Animats 11y ago
Right. C++ does not allow null references. I've seen this before from the "I can use null references because I know what I'm doing." crowd. It's really a problem of C++, though, that it's possible to create null references. References were an afterthought in C++ (Strostup admits "this" should have been a reference) and it shows. The abstraction is leaky. Rust is stricter about references not being null, as in you get a compile time error if you try.
- makecheck 11y ago
  Invalid references are a GOOD thing. The problem is that the C++ language does not allow sane behavior for the common case of objects going away. The C++ language creates the impression that holding a reference is stable, when in fact it is still possible for a reference to point to bogus memory (same as a dangling pointer). The C++ reference starts out on the right track with some nice compile-time guarantees like required initialization but then messes everything up by being immutable. The memory can be deallocated, and people with references are screwed; they cannot possibly change their own state to reflect the fact that the object is now gone. And C++ has some inconsistent hacks, such as the fact that a "const" reference to a temporary object will prevent object deallocation until scope exit but this is not the case for other uses of references. Compare that behavior to something like Objective-C's "weak" properties, where ANY weak pointer to an object is set to 0 when the target object is destroyed. This guarantees that the property values will have one of two values: a pointer to valid memory, or "nil"; never a bogus pointer. In addition, Objective-C ignores messages sent to "nil". While clearly this can still create hurdles for debugging, it is fantastic for end users because the program itself is quite stable. The language created facilities for making invalid references hard, and mostly eliminated the penalty for screwing up.

by tines 11y ago

Animats 11y ago

Right. C++ does not allow null references. I've seen this before from the "I can use null references because I know what I'm doing." crowd. It's really a problem of C++, though, that it's possible to create null references. References were an afterthought in C++ (Strostup admits "this" should have been a reference) and it shows. The abstraction is leaky. Rust is stricter about references not being null, as in you get a compile time error if you try.

makecheck 11y ago
Invalid references are a GOOD thing. The problem is that the C++ language does not allow sane behavior for the common case of objects going away. The C++ language creates the impression that holding a reference is stable, when in fact it is still possible for a reference to point to bogus memory (same as a dangling pointer). The C++ reference starts out on the right track with some nice compile-time guarantees like required initialization but then messes everything up by being immutable. The memory can be deallocated, and people with references are screwed; they cannot possibly change their own state to reflect the fact that the object is now gone. And C++ has some inconsistent hacks, such as the fact that a "const" reference to a temporary object will prevent object deallocation until scope exit but this is not the case for other uses of references. Compare that behavior to something like Objective-C's "weak" properties, where ANY weak pointer to an object is set to 0 when the target object is destroyed. This guarantees that the property values will have one of two values: a pointer to valid memory, or "nil"; never a bogus pointer. In addition, Objective-C ignores messages sent to "nil". While clearly this can still create hurdles for debugging, it is fantastic for end users because the program itself is quite stable. The language created facilities for making invalid references hard, and mostly eliminated the penalty for screwing up.