C++ doesn't have delegates, and D doesn't have member function
pointers. Resolving virtual functions is done while you take its
address in D, while in C++ the member function pointer type contains
holds the vtable offset (or several in the case of multiple
inheritance) which gets resolved only when you call the function.
If you want the C++ behaviour, try using a delegate literal as a
trampoline that gets the object as a parameter to then call your
function:
void delegate(B b) dg = (B b) { b.fun(); };
dg(d);
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

C++ doesn't have delegates, and D doesn't have member function pointers.
Resolving virtual functions is done while you take its address in D,
while in C++ the member function pointer type contains holds the vtable
offset (or several in the case of multiple inheritance) which gets
resolved only when you call the function.
If you want the C++ behaviour, try using a delegate literal as a
trampoline that gets the object as a parameter to then call your function:
void delegate(B b) dg = (B b) { b.fun(); };
dg(d);

Thank you. That was very helpful.
What's the rational for this behavior though? Resolving the address of a
virtual function at compile time seems a little counter-intuitive to me.
I guess this way is slightly more efficient.

C++ doesn't have delegates, and D doesn't have member function pointers.
Resolving virtual functions is done while you take its address in D,
while in C++ the member function pointer type contains holds the vtable
offset (or several in the case of multiple inheritance) which gets
resolved only when you call the function.
If you want the C++ behaviour, try using a delegate literal as a
trampoline that gets the object as a parameter to then call your function:
void delegate(B b) dg = (B b) { b.fun(); };
dg(d);

Thank you. That was very helpful.
What's the rational for this behavior though? Resolving the address of a
virtual function at compile time seems a little counter-intuitive to me.
I guess this way is slightly more efficient.

A delegate literal consists of a function pointer and a context pointer. There
is
no polymorphism in that. A member function is a normal function you can take the
address of.
In general, you shouldn't update one of (ptr,funcptr) without updating the other
unless you have good reasons to do so and know exactly what you are doing.
Not having member pointers is AFAIK a direct consequence of the fact that nobody
uses them in C++ and almost nobody even knows that they exist.
Furthermore, their implementation is too involved, given their limited
usefulness.
Cheers,
-Timon

C++ doesn't have delegates, and D doesn't have member function pointers.
Resolving virtual functions is done while you take its address in D,
while in C++ the member function pointer type contains holds the vtable
offset (or several in the case of multiple inheritance) which gets
resolved only when you call the function.
If you want the C++ behaviour, try using a delegate literal as a
trampoline that gets the object as a parameter to then call your function:
void delegate(B b) dg = (B b) { b.fun(); };
dg(d);

Thank you. That was very helpful.
What's the rational for this behavior though? Resolving the address of a
virtual function at compile time seems a little counter-intuitive to me.
I guess this way is slightly more efficient.

A delegate literal consists of a function pointer and a context pointer. There
is
no polymorphism in that. A member function is a normal function you can take
the
address of.

I see.

In general, you shouldn't update one of (ptr,funcptr) without updating the
other
unless you have good reasons to do so and know exactly what you are doing.
Not having member pointers is AFAIK a direct consequence of the fact that
nobody
uses them in C++ and almost nobody even knows that they exist.
Furthermore, their implementation is too involved, given their limited
usefulness.
Cheers,
-Timon

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.
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?

C++ doesn't have delegates, and D doesn't have member function pointers.
Resolving virtual functions is done while you take its address in D,
while in C++ the member function pointer type contains holds the vtable
offset (or several in the case of multiple inheritance) which gets
resolved only when you call the function.
If you want the C++ behaviour, try using a delegate literal as a
trampoline that gets the object as a parameter to then call your function:
void delegate(B b) dg = (B b) { b.fun(); };
dg(d);

Thank you. That was very helpful.
What's the rational for this behavior though? Resolving the address of a
virtual function at compile time seems a little counter-intuitive to me.
I guess this way is slightly more efficient.

A delegate literal consists of a function pointer and a context pointer. There
is
no polymorphism in that. A member function is a normal function you can take
the
address of.

I see.

In general, you shouldn't update one of (ptr,funcptr) without updating the
other
unless you have good reasons to do so and know exactly what you are doing.
Not having member pointers is AFAIK a direct consequence of the fact that
nobody
uses them in C++ and almost nobody even knows that they exist.
Furthermore, their implementation is too involved, given their limited
usefulness.
Cheers,
-Timon

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.
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 above premise is incorrect in that it compares to different concepts. A
delegate is a closure whereas a c++ member function pointer is not. This means
it
captures the context in which the code was run. In the case of a method call,
that
context would be the specific instance when the delegate was created hence it
cannot and should not be polymorphic.
Regarding signal/slot designs: see for example C#'s implementation - this is
incorporated into the language as "events" which are simply arrays of delegates.
Implementing this via member function pointers is actually the uncommon case
since
most other languages use closures.

C++ doesn't have delegates, and D doesn't have member function pointers.
Resolving virtual functions is done while you take its address in D,
while in C++ the member function pointer type contains holds the vtable
offset (or several in the case of multiple inheritance) which gets
resolved only when you call the function.
If you want the C++ behaviour, try using a delegate literal as a
trampoline that gets the object as a parameter to then call your function:
void delegate(B b) dg = (B b) { b.fun(); };
dg(d);

Thank you. That was very helpful.
What's the rational for this behavior though? Resolving the address of a
virtual function at compile time seems a little counter-intuitive to me.
I guess this way is slightly more efficient.

A delegate literal consists of a function pointer and a context pointer. There
is
no polymorphism in that. A member function is a normal function you can take
the
address of.

I see.

In general, you shouldn't update one of (ptr,funcptr) without updating the
other
unless you have good reasons to do so and know exactly what you are doing.
Not having member pointers is AFAIK a direct consequence of the fact that
nobody
uses them in C++ and almost nobody even knows that they exist.
Furthermore, their implementation is too involved, given their limited
usefulness.
Cheers,
-Timon

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.
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 above premise is incorrect in that it compares to different concepts. A
delegate is a closure whereas a c++ member function pointer is not. This means
it
captures the context in which the code was run. In the case of a method call,
that
context would be the specific instance when the delegate was created hence it
cannot and should not be polymorphic.
Regarding signal/slot designs: see for example C#'s implementation - this is
incorporated into the language as "events" which are simply arrays of
delegates.
Implementing this via member function pointers is actually the uncommon case
since
most other languages use closures.

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 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

What's the rational for this behavior though? Resolving the address of
a virtual function at compile time seems a little counter-intuitive to
me.

The address for a virtual function isn't necessarily resolved at
compile time. It is resolved at the point where you use the address-of
operator, and that'll check the vtable at runtime if necessary.
In D:
B b = new D;
auto dg = &b.foo; // address is resolved at runtime by looking at the vtable
dg(); // calls D.foo
In C++:
void (B::*fptr)() = &B::foo;
B b = new D;
b.*fptr(); // vtable lookup here, calls D.foo

I guess this way is slightly more efficient.

It certainly is if you call the delegate more often than you create one.
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/