Skybuck Flying said:
Virtual methods is absolutely not a solution.
It introduces more overhead then the code itself.
Yes.
Different code paths increases the executable size which is also not nice.
There's no reason you could have your program loader substitute the
appropriate routines at load time. As-is, program loaders have to do all
sorts of "fix ups" (patches) since they generally have no way of knowing what
memory location the program will be loaded at; modifying the program loader to
play "musical subroutines" isn't that much of a stretch.
If you think about it, just using dynamic link libraries (DLLs) is the same
idea, although you're still going through one dereferencing (call) each time
you invoke a function.
You have some good ideas, Skybuck, but the other posters who are saying that
these are well-known problems with various solutions that have been considered
and applied as necessary for decades now are correct. You really should spend
some time reading up on computer architecture "through the ages" to learn
about how many problems like this have been solved and what the ramifications
and "unintended consequences" were. (They're often quite interesting... stuff
like how someone thought it would be useful to have a hard drive perform
searches for particular data sequences but, as it turned out, it didn't take
long before the computer's PC was so much faster than the hard drives that
this hard drive "feature" was the slowest way to search, etc. Something very
similar happened with the Commodore Amiga computers back in the '80s:
Originally the ~8MHz 68000 CPU was "assisted" by what one might call graphics
co-processors; just scrolling a line of text on the (graphics mode) screen was
done by a blitter. As time went by, Commodore eventually had Amigas with
68030 CPUs running at 25MHz... still coupled with the 8MHz custom chips. At
that point, it was noticeably faster to have the CPU do the blitting rather
than the co-processors!)
---Joel