> Even C++ lets you store the address of the member function and lets you invoke it with an instance later.
Not for virtual member functions (not that I've been able to find). C++ is geared towards generating optimal executables. Since the type of the object is known at compile-time, the particular function used for that type is known, and the compiler will generate code that applies for it.
This is why C++ uses mangled names: to discriminate between identically named functions of different types and signatures.
>There's one big difference in terms of convenience in many common implementations of classes and methods.
Which ones?
>However, it is much more rare to be able to store B in a variable and supply it "later". Often, you must store A.B:
How is it rare? Smalltalk doesn't require you to specify the receiver when storing a symbol. Neither does Objective-C (selector). Neither does Ruby. Nor Java.
Which commonly used languages require one to have the receiver tied to the method when memoized? C++ is the only one I'm aware of. So it might be rare to do it in C++, but not in OOP generally.
I appreciate the effort you put into your work, and it certainly looks complete. Thanks for sharing it. But I hope you formatted the book so it's easier to read than your landing page. Center alignment is hard on the eyes.
Not for virtual member functions (not that I've been able to find). C++ is geared towards generating optimal executables. Since the type of the object is known at compile-time, the particular function used for that type is known, and the compiler will generate code that applies for it.
This is why C++ uses mangled names: to discriminate between identically named functions of different types and signatures.