On 6/28/2011 7:13 PM, Steven Schveighoffer wrote:
On Mon, 27 Jun 2011 22:23:32 -0400, Nub Public <nubpub...@gmail.com> wrote:
I have to disagree on this.
Member function pointers are useful in many event handling systems.
Imagine a signal and slot system. To register a member function as a
slot, the most direct and intuitive way is to take a member function
pointer. In c++0x and boost, <function>, <functional> and related
libraries all work with member function pointers.
My premise is simple: a virtual function should always be resolved by
the dynamic identity of the object, regardless of whether it is called
directly or through a function pointer.
This can be had using delegates, but it's not straightforward, you need
to do a little bit of extra work.
For example, if you did this:
class A
{
final void callFoo() { foo(); }
void foo() {writeln("A");}
}
class B : A
{
void foo() {writeln("B");}
}
A delegate to callFoo would do polymorphism, even when you change the
context pointer (to a compatible instance).
Note that it is highly unusual to change anything about a delegate, as
type checking the context pointer is out the window. In fact, it is the
property of delegates which makes them so useful -- because you don't
have to care what the type of the context pointer is, the delegate's
type does not depend on it.
Perhaps the contextptr of D delegate cannot do this because it can
refer to the enclosing context besides an object. But I'd love it for
D to have the functionality of a truly polymorhic member function
pointer. Maybe the restrictions on the keyword "function" can be
relaxed to work with such a pointer?
The easiest thing to do is the suggestion from Michel Fortin -- create a
function/delegate that accepts the base type. This is much safer as
well. I would be highly suspect of code that alters any delegate
components.
-Steve
I see. Thank you.
