www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - class scope virtual template functions

reply BCS <ao pathlink.com> writes:
Somewhere IIRC the spec says that classes can't have template methods that 
operate as virtual functions. This is because it would quickly become a
nightmare 
trying to put together the v-table because only the linker would really know 
how many different function are in it.

However in highly limited cases, this is not an issue. 

1) the template members are enumerations (just build the whole set)
2) the function has no parameters (only one version can be built)
3) no general form of the template exists, only explicit specializations 
(ditto enum)
4) class scope aliases of member templates are used. (instance the template 
and stuff it in as a normal function)

There is also an interesting possibility suggested by #2: allow a template 
with no args that is penalized for the actual type of the specific object

Example:

class A
{
  char[] Name(this)()  // "this" is a pseudo arg
  { return typeof(this).stringof; }
}
class B : A {}

writef("%s\n", (new A).Name); // outputs "A"
writef("%s\n", (new B).Name); // outputs "B"

Thoughts?

I have some thoughts on how to use this functionality, but it's to ill-formed 
at this time to fit in this margin.
May 29 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 However in highly limited cases, this is not an issue.
 1) the template members are enumerations (just build the whole set)
 2) the function has no parameters (only one version can be built)
 3) no general form of the template exists, only explicit specializations 
 (ditto enum)
 4) class scope aliases of member templates are used. (instance the 
 template and stuff it in as a normal function)

True, but now you have the issue that minor, seemingly innocuous changes to a template function can have dramatic changes to its behavior. It's a lot easier to understand "template functions are not virtual" than "template functions are not virtual except in these rather complex scenarios." If you need virtual behavior from a template function, the best way is to wrap a virtual function call within it.
May 29 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 However in highly limited cases, this is not an issue.
 1) the template members are enumerations (just build the whole set)
 2) the function has no parameters (only one version can be built)
 3) no general form of the template exists, only explicit
 specializations
 (ditto enum)
 4) class scope aliases of member templates are used. (instance the
 template and stuff it in as a normal function)

changes to a template function can have dramatic changes to its behavior. It's a lot easier to understand "template functions are not virtual" than "template functions are not virtual except in these rather complex scenarios." If you need virtual behavior from a template function, the best way is to wrap a virtual function call within it.

in my case, I need this syntax this.Templet!("foo")(arg) to be virtual. The use case is inside of dparse where I have template code calling template code.
May 29 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 in my case, I need this syntax
 
 this.Templet!("foo")(arg)
 
 to be virtual.
 
 The use case is inside of dparse where I have template code calling 
 template code.

You could try parameterizing the class enclosing the template, rather than the template.
May 29 2008
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 in my case, I need this syntax
 
 this.Templet!("foo")(arg)
 
 to be virtual.
 
 The use case is inside of dparse where I have template code calling
 template code.
 

than the template.

I need to be able to have more than one version of the template for a fuller example class A { void Template(char[] s: "foo")(int i) {writef("Hello %d\n", i);} void Template(char[] s: "bob")(int i) {writef("See ya %d\n", i);} } class B : A { void Template(char[] s: "foo")(int i) {for(int j=0;j<i;j++) writef("Hello\n");} void Template(char[] s: "bob")(int i) {for(int j=0;j<i;j++) writef("See ya\n");}} } A a = someA(); a.Template!("foo")(5); a.Template!("bob")(5); // same a, same class different function the actual used code looks something like this: void CallIt(T,char[] str)(T it) { it.Template!(str)(arg) } (The reason for that form is rather complicated and irrelevant to this thread)
May 29 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
BCS wrote:
 Reply to Walter,
 
 BCS wrote:

 in my case, I need this syntax

 this.Templet!("foo")(arg)

 to be virtual.

 The use case is inside of dparse where I have template code calling
 template code.

than the template.

I need to be able to have more than one version of the template for a fuller example class A { void Template(char[] s: "foo")(int i) {writef("Hello %d\n", i);} void Template(char[] s: "bob")(int i) {writef("See ya %d\n", i);} } class B : A { void Template(char[] s: "foo")(int i) {for(int j=0;j<i;j++) writef("Hello\n");} void Template(char[] s: "bob")(int i) {for(int j=0;j<i;j++) writef("See ya\n");}} } A a = someA(); a.Template!("foo")(5); a.Template!("bob")(5); // same a, same class different function the actual used code looks something like this: void CallIt(T,char[] str)(T it) { it.Template!(str)(arg) } (The reason for that form is rather complicated and irrelevant to this thread)

How about creating normal methods, and normal method override hierarchy/lineages, and then creating a template that simply selects the desired method lineage, like this: --- --- module test; class A { void Template_foo(int i) {writef("Hello %d\n", i);} void Template_bob(int i) {writef("See ya %d\n", i);} template Template(string s: "foo") { alias Template_foo Template; } template Template(string s: "bob") { alias Template_bob Template; } } class B : A { override void Template_foo(int i) {for(int j=0;j<i;j++) writef("Hello\n");} override void Template_bob(int i) {for(int j=0;j<i;j++) writef("See ya\n");} } void main() { A a = new B(); a.Template!("foo")(5); a.Template!("bob")(5); // same a, same class different function } --- --- If you have many method choices, a mixin could be created to automatically generate all template specializations, such as: mixin TemplateAliases!("Template", ["foo", "bob", "bar", "xpto"]); which would generate lines like: template Template(string s: "foo") { alias Template_foo Template; } etc. -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 14 2008
parent BCS <ao pathlink.com> writes:
Reply to Bruno,

 module test;
 class A
 {
 void Template_foo(int i) {writef("Hello %d\n", i);}
 void Template_bob(int i) {writef("See ya %d\n", i);}
 template Template(string s: "foo") { alias Template_foo Template; }
 template Template(string s: "bob") { alias Template_bob Template; }
 }
 class B : A
 {
 override void Template_foo(int i) {for(int j=0;j<i;j++)
 writef("Hello\n");}
 override void Template_bob(int i) {for(int j=0;j<i;j++) writef("See
 ya\n");}
 }

I think that might work in some cases (maybe even mine). However In my cases the called functions are generated so once I need to generate different names for the functions I might as well go with mixins for the calls and then there is no point in using templates. But even if it can be made to work it seems so klugey... Walter: How restrictive would the rules have to be before templates functions could be virtual? For my case I could tag them with an extra attribute, make sure there are no non virtual ones and a lot of other things.
Jun 15 2008
prev sibling parent reply janderson <askme me.com> writes:
BCS wrote:
 Reply to Walter,
 
 BCS wrote:

 However in highly limited cases, this is not an issue.
 1) the template members are enumerations (just build the whole set)
 2) the function has no parameters (only one version can be built)
 3) no general form of the template exists, only explicit
 specializations
 (ditto enum)
 4) class scope aliases of member templates are used. (instance the
 template and stuff it in as a normal function)

changes to a template function can have dramatic changes to its behavior. It's a lot easier to understand "template functions are not virtual" than "template functions are not virtual except in these rather complex scenarios." If you need virtual behavior from a template function, the best way is to wrap a virtual function call within it.

in my case, I need this syntax this.Templet!("foo")(arg) to be virtual. The use case is inside of dparse where I have template code calling template code.

You could use a functor/proxy type thing. That is return a separate object for each class level that has opCall overloaded. The opCall could be templated. The functor object probably could be generalized so that you could use it in any case you needed a virtual function (it could callback its owner by template or maybe delegate). Of course that's more complex then a simple template virtual inheritance however it does provide more functionality as well. -Joel
May 29 2008
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
janderson wrote:
 You could use a functor/proxy type thing.  That is return a separate 
 object for each class level that has opCall overloaded.  The opCall 
 could be templated.  The functor object probably could be generalized so 
 that you could use it in any case you needed a virtual function (it 
 could callback its owner by template or maybe delegate).

I don't understand this. You seem to be suggesting moving the template to a functor and having inheritors of the original class return a different functor. But unless that functor is virtual, you simply can't do that. You'd need to call a different method for each inheritor, or you'd need inheritance with the functors. The former is not virtual; the latter simply returns us to the original problem.
May 30 2008
parent reply janderson <askme me.com> writes:
Chris Wright wrote:
 janderson wrote:
 You could use a functor/proxy type thing.  That is return a separate 
 object for each class level that has opCall overloaded.  The opCall 
 could be templated.  The functor object probably could be generalized 
 so that you could use it in any case you needed a virtual function (it 
 could callback its owner by template or maybe delegate).

I don't understand this. You seem to be suggesting moving the template to a functor and having inheritors of the original class return a different functor. But unless that functor is virtual, you simply can't do that. You'd need to call a different method for each inheritor, or you'd need inheritance with the functors. The former is not virtual; the latter simply returns us to the original problem.

Something like: class A { templateCallback()() {} //template TemplateMaker Templet() { return new TemplateMaker(this, templateCallbackFunc); } } class A : B { templateCallback2()() {} //template TemplateMaker Templet() { return new TemplateMaker(this, templateCallbackFunc2); } } Then the templateMaker would be: class TemplateMaker(class, callback) //Functor/proxy { TemplateMaker(class, callback) { record of stuff ... } void opCall(T...)(T arg) { recordedclass->recoredcallback(arg); } } Call it like: this.Templet()!("foo")(arg) //Might simplify to due to D's magic property stuff this.Templet!("foo")(arg) Something like that. Haven't tried it so don't know what massaging would be needed and if it would work. -Joel
May 30 2008
parent reply Chris Wright <dhasenan gmail.com> writes:
janderson wrote:
 Something like:
 
 class A
 {
   templateCallback()() {} //template
   TemplateMaker Templet() { return new TemplateMaker(this, 
 templateCallbackFunc); }
 }
 
 
 class A : B
 {
   templateCallback2()() {} //template
   TemplateMaker Templet() { return new TemplateMaker(this, 
 templateCallbackFunc2); }
 }
 
 
 Then the templateMaker would be:
 
 class TemplateMaker(class, callback) //Functor/proxy
 {
    TemplateMaker(class, callback) { record of stuff ... }
 
    void opCall(T...)(T arg) { recordedclass->recoredcallback(arg); }
 }
 
 Call it like:
 
 this.Templet()!("foo")(arg)
 
 //Might simplify to due to D's magic property stuff
 this.Templet!("foo")(arg)
 
 Something like that. Haven't tried it so don't know what massaging would 
 be needed and if it would work.
 
 -Joel

If TemplateMaker is templated, then you can't return it, just an instantiation of it. This only allows you to access one template through it. If TemplateMaker is not templated, then it requires virtual templates in order to work; it's expecting a BaseClass, and even if it got a DerivedClass, it only knows about the template on BaseClass, so that's what it uses.
May 30 2008
parent reply janderson <askme me.com> writes:
Chris Wright wrote:
 janderson wrote:
 Something like:

 class A
 {
   templateCallback()() {} //template
   TemplateMaker Templet() { return new TemplateMaker(this, 
 templateCallbackFunc); }
 }


 class A : B
 {
   templateCallback2()() {} //template
   TemplateMaker Templet() { return new TemplateMaker(this, 
 templateCallbackFunc2); }
 }


 Then the templateMaker would be:

 class TemplateMaker(class, callback) //Functor/proxy
 {
    TemplateMaker(class, callback) { record of stuff ... }

    void opCall(T...)(T arg) { recordedclass->recoredcallback(arg); }
 }

 Call it like:

 this.Templet()!("foo")(arg)

 //Might simplify to due to D's magic property stuff
 this.Templet!("foo")(arg)

 Something like that. Haven't tried it so don't know what massaging 
 would be needed and if it would work.

 -Joel

If TemplateMaker is templated, then you can't return it, just an instantiation of it. This only allows you to access one template through it. If TemplateMaker is not templated, then it requires virtual templates in order to work; it's expecting a BaseClass, and even if it got a DerivedClass, it only knows about the template on BaseClass, so that's what it uses.

Sorry, I haven't actually tried this example. Its an C++ trick I've used for other purposes. I think it looks something like this: class TemplateMaker { TemplateMakera(delegate) { record of stuff ... } //This might be a template too, can't remember. Maybe a reinterpret cast somewhere too. void opCall(T...)(T arg) { delegate->recoredcallback(arg); } } I'm sure given enough time it could be done in D like C++. I don't want to put in the effort though atm. -Joel
May 30 2008
parent reply Chris Wright <dhasenan gmail.com> writes:
janderson wrote:
 Sorry, I haven't actually tried this example.  Its an C++ trick I've 
 used for other purposes.  I think it looks something like this:
 
 class TemplateMaker
 {
    TemplateMakera(delegate) { record of stuff ... } //This might be a 
 template too, can't remember. Maybe a reinterpret cast somewhere too.
    void opCall(T...)(T arg) { delegate->recoredcallback(arg); }
 }
 
 I'm sure given enough time it could be done in D like C++.  I don't want 
 to put in the effort though atm.
 
 -Joel

Delegates can work. But you have to know the arguments to the template in advance. Everything I can think of to implement virtual templates requires virtual templates. With the exception of hacking the compiler, which would provide a means of providing virtual templates. It's a straightforward matter, so it wouldn't require redesign like const, though the initial effort might well be greater.
May 31 2008
parent janderson <askme me.com> writes:
Chris Wright wrote:
 janderson wrote:
 Sorry, I haven't actually tried this example.  Its an C++ trick I've 
 used for other purposes.  I think it looks something like this:

 class TemplateMaker
 {
    TemplateMakera(delegate) { record of stuff ... } //This might be a 
 template too, can't remember. Maybe a reinterpret cast somewhere too.
    void opCall(T...)(T arg) { delegate->recoredcallback(arg); }
 }

 I'm sure given enough time it could be done in D like C++.  I don't 
 want to put in the effort though atm.

 -Joel

Delegates can work. But you have to know the arguments to the template in advance. Everything I can think of to implement virtual templates requires virtual templates. With the exception of hacking the compiler, which would provide a means of providing virtual templates. It's a straightforward matter, so it wouldn't require redesign like const, though the initial effort might well be greater.

I agree that having virtual templates in the language would be nice. I don't like using workaround because they are less intuitive. -Joel
May 31 2008
prev sibling parent BCS <ao pathlink.com> writes:
Reply to janderson,

 You could use a functor/proxy type thing.  That is return a separate
 object for each class level that has opCall overloaded.  The opCall
 could be templated.  The functor object probably could be generalized
 so that you could use it in any case you needed a virtual function (it
 could callback its owner by template or maybe delegate).
 
 Of course that's more complex then a simple template virtual
 inheritance however it does provide more functionality as well.
 
 -Joel
 

It would be simpler to use a string mixin to generate functions with the string encoded into the function name. It could get ugly but a non virtual template function could get around that. But still, the proposed solution is "possible" and a lot cleaner.
May 30 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:
 
 True, but now you have the issue that minor, seemingly innocuous changes 
 to a template function can have dramatic changes to its behavior. It's a 
 lot easier to understand "template functions are not virtual" than 
 "template functions are not virtual except in these rather complex 
 scenarios."

I'd prefer the compiler to require non-virtual functions to be declared final or private. This then allows the compiler to nority the programmer of limitations instead of the spec. It'd also open the door for proposals like this one...
May 29 2008
parent BCS <ao pathlink.com> writes:
Reply to Jason,


 I'd prefer the compiler to require non-virtual functions to be
 declared final or private. This then allows the compiler to nority the
 programmer of limitations instead of the spec. It'd also open the door
 for proposals like this one...
 

I agree with the suggestion for both reasons
May 29 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
 1) the template members are enumerations (just build the whole set)

Much to my frustration, D's enums do not represent a completely enumerated set. This causes all kinds of problems such as invalidating your example, preventing a default toString method, and mangling otherwise clean switch statements.
May 29 2008
parent BCS <ao pathlink.com> writes:
Reply to Jason,

 1) the template members are enumerations (just build the whole set)
 

enumerated set. This causes all kinds of problems such as invalidating your example, preventing a default toString method, and mangling otherwise clean switch statements.

Just because /you and I/ can't get the full set, doesn't say the compiler can't. (but point taken) OTOH using enums as OR'ed bit flags or having more than one element with the same value sinks it just as sunk.
May 29 2008
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
BCS wrote:
 Somewhere IIRC the spec says that classes can't have template methods 
 that operate as virtual functions. This is because it would quickly 
 become a nightmare trying to put together the v-table because only the 
 linker would really know how many different function are in it.

You also have to be sure to instantiate all overrides of the template. But these are manageable, even so. You can keep a list of instantiations for each template alongside the object file, plus a list of overrides. Then as a pre-linking step, you instantiate them all. This would be a HUGE advantage. Want to support user-defined interceptors on whatever your library is doing? If your library does any nontrivial stuff at compiletime, you can't. Not without virtual templates.
 However in highly limited cases, this is not an issue.
 1) the template members are enumerations (just build the whole set)
 2) the function has no parameters (only one version can be built)
 3) no general form of the template exists, only explicit specializations 
 (ditto enum)
 4) class scope aliases of member templates are used. (instance the 
 template and stuff it in as a normal function)

You can just use a switch statement, but that gets unmaintainable before too long.
 There is also an interesting possibility suggested by #2: allow a 
 template with no args that is penalized for the actual type of the 
 specific object
 
 Example:
 
 class A
 {
  char[] Name(this)()  // "this" is a pseudo arg
  { return typeof(this).stringof; }
 }
 class B : A {}
 
 writef("%s\n", (new A).Name); // outputs "A"
 writef("%s\n", (new B).Name); // outputs "B"
 
 Thoughts?
 
 I have some thoughts on how to use this functionality, but it's to 
 ill-formed at this time to fit in this margin.

Dconstructor needs this. My dependency injection library has the following basic API: class Builder { T get(T)(); } The best way I've seen to allow user-defined interceptors is: class Builder (TInterceptors...) { // Actually working with this is quite a pain. private TInterceptors _interceptors; T get (T) () { foreach (interceptor; _interceptors) { if (T t = interceptor.handle!(T)(this)) { return t; } } // ... } } This isn't very good; you can't add or remove interceptors at runtime, and you need to add all the interceptors at the same place. Plus it's really ugly to work with a type tuple variable. I'd rather an interface like: interface IBuildInterceptor { T handle(T)(IBuilder builder); } interface IBuilder { T get(T)(); void addInterceptor(IBuildInterceptor interceptor); } In .NET or Java, you wouldn't think twice about how to create such an interface. In D, you don't even think once; you know it's impossible.
May 29 2008
parent BCS <ao pathlink.com> writes:
Reply to Chris,

 BCS wrote:
 
 You can just use a switch statement, but that gets unmaintainable
 before too long.
 

Offten, yes (to both parts), but if the return types and or thenumber and types of the arguments change you are sunk.
May 30 2008