View mode: basic / threaded / horizontal-split · Log in · Help
May 04, 2012
Re: virtual method pointer
Does this have an overhead over calling virtual method directly?

On Fri, May 4, 2012 at 1:30 PM, jerro <a@a.com> wrote:
> On Thursday, 3 May 2012 at 18:47:11 UTC, Gor Gyolchanyan wrote:
>>
>> I need to get a pointer to a virtual method, which is in turn a
>> function pointer, being set by virtual method binding.
>> Can anyone, please, tell me how to get it? Taking the delegate of the
>> method won't do, because I need it to behave exactly as a virtual
>> method call, except I pass the "this" explicitly.
>> I need this in an event handling mechanism I'm making. You derive from
>> the Sink class, passing your static type to the constructor, which
>> scans your virtual methods, that conform to specific requirements and
>> extracts them into an array, which later uses to dispatch the incoming
>> events.
>> It will feel much like a run-time virtual template method.
>
>
> If I understand you correctly, you could use something like this
>
> template methodToFunction(A, string method)
> {
>     auto methodToFunction(A a, ParameterTypeTuple!(mixin("A." ~ method)) p)
>     {
>         return mixin("&a." ~ method)(p);
>     }
> }
>
> If you use it like this:
>
> class Foo
> {
>    int m;
>
>    void bar(int a, string b)
>    {
>        writefln("%s\t%s\t%s", m, a, b);
>    }
> }
>
> class Child: Foo
> {
>    void bar(int a, string b)
>    {
>        writeln("child");
>    }
> }
>
> void main()
> {
>    auto foo = new Foo;
>    foo.m = 1;
>    auto child = new Child;
>    auto bar = &methodToFunction!(Foo, "bar");
>    bar(foo, 2, "3");
>    bar(child, 2, "3");
> }
>
> It prints:
>
> 1       2       3
> child
>
> It won't work correctly with overloading, though. It could
> be made to work with overloading, but then you would
> have to pass all the parameter types of the method to
> the methodToFunction template.



-- 
Bye,
Gor Gyolchanyan.
May 04, 2012
Re: virtual method pointer
On Friday, 4 May 2012 at 09:51:51 UTC, Gor Gyolchanyan wrote:
> Does this have an overhead over calling virtual method directly?

If you call the function directly, it probably gets inlined.
If you call it through a function pointer, it does have some
overhead over calling the virtual method directly.
May 04, 2012
Re: virtual method pointer
So, the only overhead in making a virtual call this way over calling
the method directly is exactly 1 extra function call?

On Fri, May 4, 2012 at 2:02 PM, jerro <a@a.com> wrote:
> On Friday, 4 May 2012 at 09:51:51 UTC, Gor Gyolchanyan wrote:
>>
>> Does this have an overhead over calling virtual method directly?
>
>
> If you call the function directly, it probably gets inlined.
> If you call it through a function pointer, it does have some
> overhead over calling the virtual method directly.



-- 
Bye,
Gor Gyolchanyan.
May 04, 2012
Re: virtual method pointer
On Friday, 4 May 2012 at 10:05:54 UTC, Gor Gyolchanyan wrote:
> So, the only overhead in making a virtual call this way over 
> calling
> the method directly is exactly 1 extra function call?

I guess so. You are calling a function that does a virtual call 
and doesn't do anything else, so what other overhead could there 
be?
May 04, 2012
Re: virtual method pointer
Great! Thanks!
After I'm done with this, I'll propose adding it to Phobos.
A genuine dynamic dispatch mechanism would be very useful.

On Fri, May 4, 2012 at 6:04 PM, jerro <a@a.com> wrote:
> On Friday, 4 May 2012 at 10:05:54 UTC, Gor Gyolchanyan wrote:
>>
>> So, the only overhead in making a virtual call this way over calling
>> the method directly is exactly 1 extra function call?
>
>
> I guess so. You are calling a function that does a virtual call and doesn't
> do anything else, so what other overhead could there be?



-- 
Bye,
Gor Gyolchanyan.
May 04, 2012
Re: virtual method pointer
Did you see my solution? I think it's what you're looking for...

On Friday, 4 May 2012 at 10:05:54 UTC, Gor Gyolchanyan wrote:
> So, the only overhead in making a virtual call this way over 
> calling
> the method directly is exactly 1 extra function call?
>
> On Fri, May 4, 2012 at 2:02 PM, jerro <a@a.com> wrote:
>> On Friday, 4 May 2012 at 09:51:51 UTC, Gor Gyolchanyan wrote:
>>>
>>> Does this have an overhead over calling virtual method 
>>> directly?
>>
>>
>> If you call the function directly, it probably gets inlined.
>> If you call it through a function pointer, it does have some
>> overhead over calling the virtual method directly.
May 04, 2012
Re: virtual method pointer
Yes! Your solution looks exactly like what I wanted. The reason why I
considered additional alternatives is because your solutions looks
very fast (YES!!!), but not very portable and safe, so after testing,
if it turns out to be inconsistent, I'll have to use something else.

On Fri, May 4, 2012 at 6:12 PM, Mehrdad <wfunction@hotmail.com> wrote:
> Did you see my solution? I think it's what you're looking for...
>
>
> On Friday, 4 May 2012 at 10:05:54 UTC, Gor Gyolchanyan wrote:
>>
>> So, the only overhead in making a virtual call this way over calling
>> the method directly is exactly 1 extra function call?
>>
>> On Fri, May 4, 2012 at 2:02 PM, jerro <a@a.com> wrote:
>>>
>>> On Friday, 4 May 2012 at 09:51:51 UTC, Gor Gyolchanyan wrote:
>>>>
>>>>
>>>> Does this have an overhead over calling virtual method directly?
>>>
>>>
>>>
>>> If you call the function directly, it probably gets inlined.
>>> If you call it through a function pointer, it does have some
>>> overhead over calling the virtual method directly.
>
>
>



-- 
Bye,
Gor Gyolchanyan.
May 04, 2012
Re: virtual method pointer
Ah okay. Yeah it's not 'safe' at all... but I think the '6' comes 
from the number of members that Foo has. If you figure out how 
many methods there are in the v-table, then that should get you 
the index (though don't quote me on this... you should look at 
the compiler source code if you want to be really sure).

On Friday, 4 May 2012 at 14:16:49 UTC, Gor Gyolchanyan wrote:
> Yes! Your solution looks exactly like what I wanted. The reason 
> why I
> considered additional alternatives is because your solutions 
> looks
> very fast (YES!!!), but not very portable and safe, so after 
> testing,
> if it turns out to be inconsistent, I'll have to use something 
> else.
>
May 04, 2012
Re: virtual method pointer
I'm not going to cherry-pick methods in any case. I'll have all
methods analyzed at compile time, by iterating over the overloads of
each method and have them searched in the vtable to get their indices
at launch time. It'll be easy to construct a dynamic virtual method
call.

On Fri, May 4, 2012 at 6:26 PM, Mehrdad <wfunction@hotmail.com> wrote:
> Ah okay. Yeah it's not 'safe' at all... but I think the '6' comes from the
> number of members that Foo has. If you figure out how many methods there are
> in the v-table, then that should get you the index (though don't quote me on
> this... you should look at the compiler source code if you want to be really
> sure).
>
>
> On Friday, 4 May 2012 at 14:16:49 UTC, Gor Gyolchanyan wrote:
>>
>> Yes! Your solution looks exactly like what I wanted. The reason why I
>> considered additional alternatives is because your solutions looks
>> very fast (YES!!!), but not very portable and safe, so after testing,
>> if it turns out to be inconsistent, I'll have to use something else.
>>
>



-- 
Bye,
Gor Gyolchanyan.
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home