RFC: Adding an alternative dispatch mechanism
Austin Hastings
ah08010-d at yahoo.com
Fri Oct 1 14:00:39 PDT 2010
Howdy,
One of the design patterns that doesn't see much publicity in the
mainstream is the Flyweight pattern.
To save you a trip, Flyweight basically implements large numbers of
virtual objects - an array of bits, for example, is usually implemented
via this pattern.
Iould be nice to be able to dodge the relatively high "object tax" for
small objects, without having to sacrifice all the features that
switching from class to struct requires. That is, if each object stores
a vtable, then a class with a single int member pays a 32bit tax on
32bits of storage, and I suppose 64bits of tax on 32bits of storage in
64-bit land.
Obviously, this eventually fades away - your 1kbyte uberclass probably
isn't bothered by the tax. But I've got some 2-byte data that isn't
about to become a class, for obvious reasons.
Anyway, I'd very much like to preserve the ability to derive subclasses.
This isn't about converting to struct, but about ways to lower the cost
of being an object.
To that end, I'd like to propose a sort of opVtable - name obviously
subject to change - that would somehow report the class of the target
object, thus enabling virtual function dispatch.
This would be static type based, so if you have a reference to a
BaseClass, then obviously the call will go to BaseClass.opVtable for
resolution.
But there are lots of ways to encode type info, so BaseClass could
implement a trivial approach - all children get the same vtable (this is
Flyweight, really) - or BaseClass could use some characteristic of the
target object to determine a child class.
This is for the most part syntactic sugar. But it's pretty powerful
sugar, since there are some edge cases (the object reference is the
data) where the amount of code-around to get the same result is pretty high.
As a thinking point, consider UTF-8 "character" sequences. The objects
are variable sized, and benefit strongly from being closely packed. I
don't think anyone wants to insert 32 bits of pointer at the front of
each sequence :). But there are a LOT of different questions one might
ask about a UTF8 "object" - is it lower case? what is the upper case
version? is it in character class 'X'?
A simple implementation would use opVtable to decode enough for size and
code page info, then proceed from there. The result would be that each
pointer into a buffer was effectively an object pointer.
Comments?
=Austin
More information about the Digitalmars-d
mailing list