Any word on the return-type const syntax?

Christopher Wright dhasenan at gmail.com
Sat Dec 8 16:30:14 PST 2007


Christopher Wright wrote:
> Janice Caron wrote:
>> On 12/7/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>>> That can now be done with a template.
>>
>> Not if we're talking virtual member functions, it can't.
> 
> I dislike that limitation of virtual methods and templates, but I don't 
> see a clean and efficient way around it. I should spend a couple years 
> working on it and then publish a paper on the topic, and then submit a 
> patch to bugzilla based on the work.

Okay, it actually isn't that hard, I think, as long as you compile your 
entire application in one go. Or at least, the compiler has to have it 
all available at once.

You don't need to send anything up the inheritance tree, but you do need 
to send stuff down. You'd need to get a list, for each templated method, 
of each instantiation; then, for each class that inherits from the base 
class, you'd have to adjust the vtbl appropriately.

I'm not sure how templated methods work currently -- you can have an 
arbitrary number of instantiations for an arbitrary number of templates 
in a class, and those all affect the vtbl, and they have to do so in 
some predictable manner.

Unless you make them into global functions that have the same call style 
as regular methods rather than putting them into the vtbl, which seems 
the easiest route, you have to compile the entire application in one go. 
This is not the current case, so I conclude that templated methods are 
free methods that take a this pointer. (And it's probably been mentioned 
here.)

The vtbl is one of the main reasons that you get fast virtual method 
calls: one pointer dereference to get to the vtbl, one addition and a 
dereference to get to the method. In order to get virtual templated 
methods, you could use that idea, but in order to use a plain list, 
you'd need to fill in the vtbl at link time. That isn't actually hard, 
in theory, but you need a custom linker -- or more likely, add in a 
prelink phase to compilation just for this.

Or, you could keep a special object file (or some other convenient 
format) somewhere for virtual templated methods. If you kept all results 
from template expansion there, it'd solve the problem of multiple 
instantiation, too. However, this also involves parsing object files -- 
or some other intermediate format. And it increases the size of the 
resulting binaries if you're compiling for multiple projects. And it 
does some nasty things with order of compilation with revisions, 
probably. And it disallows building in parallel, without some locking 
mechanism on the templates file. (You'd have to recompile all modules 
which contain classes that derive from the one with the updated list of 
virtual template instantiations, but that's normal, since you're 
effectively recompiling a module they import.)

So, the method's not terribly complex, I think, but it'd be extremely 
annoying to work with. At the very least, you'd want template methods to 
be final by default so most people could ignore the whole issue.



More information about the Digitalmars-d mailing list