D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 1657 - Virtual template methods in classes
Summary: Virtual template methods in classes
Status: RESOLVED WONTFIX
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86 Linux
: P2 enhancement
Assignee: Walter Bright
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-10 08:14 UTC by Neia Neutuladh
Modified: 2015-06-09 01:14 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Neia Neutuladh 2007-11-10 08:14:56 UTC
In a class, all methods are virtual by default, with the exception of static methods and templated methods. That is, the following will not compile:

class AbstractCollection (T) {
   void addAll(U : T)(AbstractCollection!(U) collection);
}

Virtual templated methods should be allowed.
Comment 1 Walter Bright 2007-11-27 13:24:30 UTC
This works this way in D for the same reason as in C++. Virtual dispatch is done through a static table generated at compile time in the class' module. It cannot be arbitrarilly added to by other modules. There doesn't seem to be a reasonable way to implement this in a language with static typing.
Comment 2 BCS 2007-11-28 14:09:42 UTC
Maybe you can't fix it in the language, but you could in the linker:

- vtbl offsets are symbols
- build the vtbl at link time
- generate values for the offsets once you know what they should be
- go path them in for every virtual function call.

I don't know if any linker can do this but it is possible in theory. However you would run into problems with DLLs and such.
Comment 3 Brad Roberts 2007-11-28 17:44:46 UTC
Only for fully statically linked apps.  For any application involving 
.so's, they could change in nice fun arbitrary ways.  There's no linker 
(not even the app loader) that has visibility into every aspect of the set 
of code that will be running until after its way too late to be making 
vtable layout changes.

Ok, in some theory the loader could be powerful enough to freeze the 
entire app and examine the vtables, see what needs to change, walk through 
all memory to adjust any function pointers that need to be adjusted, etc.  
But it's rather far outside the bounds of reasonable for a compiled 
language. :)

Later,
Brad