On Wednesday, 5 March 2014 at 02:28:00 UTC, Nick Sabalausky wrote:
On 3/3/2014 5:35 PM, Chris wrote:
Maybe I'm a bit too philosophical about this. But consider the
following
(made up) case:
struct MyTemp(T) {
// ...
T add(T a, T b) {
if (a is string && b is string) {
return a~b; // or return a~"+"~b; or whatever
} else if (a is integer && a is integer) {
return a+b;
}
}
}
I don't know if this can be considered a "pure" template. It
is a
template of sorts, but the type specialization in the function
add makes
it a watered-down template,
Any useful template function already works that way. The mere +
operator is *not* one single operation, but a whole category of
opcodes which are chosen based on the operand's type. Thus, +
can be thought of as a built-in template that [roughly] does
this:
T opPlus(T a, T b) {
if (T is integer) {
[asm opcode for 32-bit addition] a, b
} else if (T is ubyte) {
[asm opcode for 8-bit addition] a, b
} else if (T is float) {
[asm opcode for floating point addition] a, b
}
}
Specialization is what makes function templates useful. Some of
the specialization is explicit (static if) and some is implicit
(+ operator). But without specialization (explicit or
implicit), all instantiations would be identical. If all
instantiations are identical, why even have a template in the
first place?
Yes, this is perfectly clear to me. But the opcodes only matter
to the compiler not to the programmer, i.e. the logical concept
that one number (integer, float ...) is added to another remains
the same. That's what I was saying.
The use of templates to avoid code duplication has been mentioned
(cf. Sean Kelly's post), however real duplication is rare in
specialized programs, because each function or method has it's
own specialized job, else we wouldn't have them. Even if we
suppose that we might want to cater for string, dchar, wchar
without having to write the function three times, there might be
slight differences in handling the three types so we have to fork
within the template. What you are basically doing then is to pack
three different functions (or the parts in which they differ) in
one, at programming time (not compile time). This means you
introduce three _different_ types of logic / handling mechanisms.
Philosophically this is not a pure template, imo. The question is
where does it end? Can you turn the whole program into one big
template that handles all the different types and types of logic?
(Exaggerating :-) The example I showed above is maybe not so far
fetched add(int, int) and add(string, string).
The points you made above about OOP are very good and I'm
increasingly unhappy with OOP's limitations. However, turning to
templates I find myself stuck sometimes too, and I don't feel
good about "compromising" a template by using too many if's for
different types or introducing new logic that should actually go
into a separate function / method. I'm really interested in
different approaches like templates and entities, especially if
they help optimizing code for processors and memory. However, I
sometimes think that in Software development we always hit the
same wall, whether we go from assembly to C, to OOP, to
templates. The wall is that every real world program is highly
unique and specialized and abstraction goes only so far.
One good use for templates, I figure, would be writing an
interpreter for a scripting or DSL. As in:
greeting = "Hello, " + "world!";
result = 1 + 1;
greeting = add(string, string)
result = add(int, int)
