http://d.puremagic.com/issues/show_bug.cgi?id=1657

           Summary: Virtual template methods in classes
           Product: D
           Version: 2.007
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: dhasenan@gmail.com


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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1657


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




------- Comment #1 from bugzilla@digitalmars.com  2007-11-27 13:24 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1657





------- Comment #2 from shro8822@vandals.uidaho.edu  2007-11-28 14:09 -------
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.


-- 

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