5 ms·
Under the covers, `x.f(y)` is actually something like `_ZN1X1fEi(&x, y)`, where the mangled name indicates the class of X and the type of y. The implicit 'this
by efaref 11y ago
Under the covers, `x.f(y)` is actually something like `_ZN1X1fEi(&x, y)`, where the mangled name indicates the class of X and the type of y. The implicit 'this' pointer is actually explicit in the implementation. Similarly, a call to `f(&x, y)` would actually be a call to `_Z1fP1Xi(&x, y)`, with similar reasoning.
The author is proposing that writing
f(x, y)
Which would normally only bind to the second mangled function, would bind to the first mangled function if the second is not available.
The additional proposal, that:
x.f(y)
would work in the other direction was rejected. That's a bit of a shame, as this kind of duality is powerful in languages that support it (e.g. scala).
- daemin 11y agoThis is also why functions can work on a null object and not crash, as long as they do not access instance data. Though at that stage they should be static or external.
- efaref 11y agoYes, except for calls to virtual functions, which actually become (&x)->vtbl[N](&x, y)
- twoodfin 11y agoAFAIK, this is still undefined behavior, so "can work" means "you got lucky this time, your next compiler upgrade may turn this into a crash, security vulnerability, or utterly confounding Heisenbug".
- blt 11y agoUgh, I remember seeing null `this` values used on purpose in some old Windows MFC program, or maybe it was COM... I imagine the author was an old-school C programmer who understood well how the C++ object veneer maps down to equivalent C code / assembly. From that perspective, dealing with null `this` pointers is just another way to get the compiler to spit out the assembly instructions you want, and maybe enables some elegant patterns in client code... but it's exactly the kind of thing that makes newcomers hate C++.