View mode: basic / threaded / horizontal-split · Log in · Help
January 30, 2012
Overriding Template Methods
Hi,
I don't know if this is a bug or if I'm doing something wrong, but I'm not
being able to override template methods. This can be seen with this simple code:

class Base
{
   void writeValueType( T )( T value )
   {
       writefln( "This is Base.writeValueType: value %s has type %s", value,
typeid( value ) );
   }
}

class Derived : Base
{
   override void writeValueType( T )( T value )
   {
       writefln( "This is Derived.writeValueType: value %s has type %s",
value, typeid( value ) );
   }
}

void main()
{
   Base b = new Derived();
   b.writeValueType( true );
}

The output should be:

This is Derived.writeValueType: value true has type bool

But, instead, it is:

This is Base.writeValueType: value true has type bool

Am I missing something?
January 30, 2012
Re: Overriding Template Methods
On 01/29/2012 06:23 PM, Daniel L. Alves wrote:
> Hi,
> I don't know if this is a bug or if I'm doing something wrong, but 
I'm not
> being able to override template methods. This can be seen with this 
simple code:
>
> class Base
> {
>      void writeValueType( T )( T value )
>      {
>          writefln( "This is Base.writeValueType: value %s has type 
%s", value,
> typeid( value ) );
>      }
> }
>
> class Derived : Base
> {
>      override void writeValueType( T )( T value )
>      {
>          writefln( "This is Derived.writeValueType: value %s has type 
%s",
> value, typeid( value ) );
>      }
> }
>
> void main()
> {
>      Base b = new Derived();
>      b.writeValueType( true );
> }
>
> The output should be:
>
> This is Derived.writeValueType: value true has type bool
>
> But, instead, it is:
>
> This is Base.writeValueType: value true has type bool
>
> Am I missing something?

Template member functions cannot be virtual.

One quick reason why this is so is that Derived.writeValueType would 
have to be instantiated by the compiler, for every possible type in the 
program. This would lead to almost infinitely large virtual function 
pointer table.

I don't know whether the compiler could refuse the code to compile with 
that 'override' keyword, but luckily the code is rejected as soon as you 
add the following two lines:

    Derived d = new Derived();
    d.writeValueType(true);

Only then the compiler sees the problem:

Error: function deneme.Derived.writeValueType!(bool).writeValueType 
cannot override a non-virtual function

And that kind of makes sense, because the templates are compiled only if 
they are used and only for the types that they are used with.

Ali
January 30, 2012
Re: Overriding Template Methods
Hey,
thank you very much for the explanation!

Daniel
January 30, 2012
Re: Overriding Template Methods
On Sun, Jan 29, 2012 at 06:43:39PM -0800, Ali Çehreli wrote:
[...]
> Template member functions cannot be virtual.
> 
> One quick reason why this is so is that Derived.writeValueType would
> have to be instantiated by the compiler, for every possible type in
> the program. This would lead to almost infinitely large virtual
> function pointer table.
[...]

I wonder, though, if there are ways of simulating overridable template
members by clever use of opDispatch().

Having said that, if you ever get to the point where you can't get
around needing overridable template members, then it may be a sign that
you're trying to represent simulated types by language types and
simulated objects by language objects, whereas the two are different
beasts. The solution is to work at a higher level of abstraction.

This kind of thing happens, for example, when you're trying to do, say,
a physics simulation where you have various types of particles that
interact with each other. It may be possible up to a point to represent
each type of particle as a separate class, perhaps with a class
hierarchy of some sort.

But there comes a point where you need to treat simulated types (i.e.,
particle types) as distinct from the programming language's types. I.e.,
you have a Particle class that stores an enum that represents what type
the particle is (not to be confused with the programming language's
types), and perhaps an array of attributes associated with the particle
(as opposed to coding each attribute into a distinct field). Particle
interactions then are handled by a single method that takes a string or
enum type representing what kind of interaction it is, rather than
mapping each interaction to a method.

This kind of implementation is necessary if, say, the particles have
runtime-variable attribute lists, or runtime-variable types, or even
types that emerge at runtime. Or when simulated particles don't really
behave like programming language class objects, and therefore don't map
very well onto the OO paradigm.


T

-- 
Do not reason with the unreasonable; you lose by definition.
Top | Discussion index | About this forum | D home