www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1657] New: Virtual template methods in classes

reply d-bugmail puremagic.com writes:

           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.

Nov 10 2007
next sibling parent d-bugmail puremagic.com writes:

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.

Nov 27 2007
prev sibling parent reply d-bugmail puremagic.com writes:

------- 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.

Nov 28 2007
parent Brad Roberts <braddr puremagic.com> writes:
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. :)

Nov 28 2007