More specific instantiations

bearophile bearophileHUGS at lycos.com
Tue Feb 14 04:32:33 PST 2012


Jonathan M Davis:

> I would point out that two different instantiations of the same template have 
> _nothing_ in common with one another.

Despite the optional presence of some static ifs, they share most of the algorithms. And sometimes if the algorithm doesn't change across template instantiations, then some values are the same across template instantiations.


> It's as if you instantiate a template 
> with two different set of arguments, it's as if you copied and pasted the code 
> and then adjusted it according to the arguments.

Often according to the types. So they share something important.


> As such, having a "static 
> static" variable or function which is common to them makes no more sense than 
> std.datetime.SysTime and std.container.RedBlackTree sharing a variable or 
> function. They're completely separate. Thinking that two different 
> instantiations of the same template are related is just going to cause you 
> trouble.

The following is a silly example, but it's clear.
If you implement a function template, like a shellSort(T)(T[] a), it's able to sort both an array of doubles and an array of ints. But the sequence of gaps it uses to sort items, like [1750 701 301 132 57 23 10 4 1] doesn't need to change between the int and double instantiation. The compiler is probably smart enough to put only one copy of such array in the binary, but I am not sure the compiler is able to remove it if such static variable is computed at run-time.

Any way, the post was mostly about the @templated() (and not much about the not so useful "static static" idea), that's useful when you define a class template or struct template on several template arguments, and some of its methods use only a subset of the template arguments.

Bye,
bearophile


More information about the Digitalmars-d mailing list