How to do dynamic run time binding without using virtual functions in C++

[jesoj]

Hi All,

Can anybody help me with source code to obtain dynamic run time binding without using virtual functions in C++.

I would like to use my own pointer just like VPTR and a table (array) like VTable.

Thanks in adv,
Regards,
JE

[Narue]

Aside from having everything initialized/destroyed for you by the compiler, and hiding the actual dereferencing through convenient syntax, there's really no magic to the vtable method of polymorphism. Just out of curiosity, why are you doing something manually that C++ already supports?

[jesoj]

Hi Naure,
I would like to do some performance improvement in a class contains virtual fns. A lot of objects created from this class. So I thought if I can handle it directly, then I can tune it more easily. So I asked this question.

Please give me some tips how to do this?

Thanks in adv,
Best regards,
Jeso

[Narue]

Most of the time if virtuals push the limit, there the design is too abstract to meet performance requirements in the first place. So my usual reaction is to redesign. I've seen too many code bases that were overly complex due to hacking optimizations into a design that was unsuited to the problem.

[Salem]

> So I thought if I can handle it directly, then I can tune it more easily
Do you imagine that the compiler writers' made this hopelessly inefficient just to annoy you?

Have you finished the program - no? then optimisation is a waste of your time.
Do you have real-world data / use cases - no? then optimisation is a waste of your time.

If you have both of those, have you compiled the code with profiling enabled? Again, if the answer is no, you're wasting your time.

Guessing where the performance problems are is a crap-shoot (and most of the time, people miss by a country mile).

Profile data, with real-world examples on a complete program is what it takes to figure out where the performance problems REALLY are.
That means you don't waste time optimising things which are nowhere near the critical path.

It also means (and this is very important), that you have a known working program to benchmark against (both in terms of features and performance). If your latest hack breaks the program (or makes it worse), you still have a known good example to work with.

Random optimisation hacks before you're done have a nasty habit of introducing hidden bugs which are really hard to figure out (mostly just before the product is due to ship).