www.digitalmars.com         C & C++   DMDScript  

D - Serious deficiencies in template mechanism

reply Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Hi there,

I've just recently come upon the D language and was captured right away by 
it. Of all those programming languages I've found over the years, this 
definitely is one of the most promising!

Anyway, the template mechanism has a number of deficiencies that makes it 
drop far behind that of C++. To those, who have never worked with stuff 
like the "expression template" method, this will look like minor details, 
but after implementing my own matrix library in C++ using that method, I 
definitely have come to realize the real power that lies behind the 
template concept in C++.

Two examples of what is possible in C++, which I could not find in D:

-------------------------
* Templated functions - allowing stuff like:

        template <typename T>
        T special_addition(T a,T b) { ... }

i.e. a function that takes two arguments of an arbitrary -- but identical -- 
type. Of course, the concept goes far beyond that and is absolutely 
indispensible in many cases.

-------------------------
* Integers as template arguments:

        template <int N>
        class Vector {
                double data[N];
        };

making Vector<2> a different type than Vector<3>, allowing stuff like direct 
vector or matrix manipulations via operators with complete type checking. 
(Going far beyond the simple possibilities of direct array manipulations in 
D.)

-------------------------
The one thing that I dislike most about C++ templates, and which has been 
carried over to D as well, is, that template parameters are not typed. I.e.
if I have:
        template <typename T>
        class Test {
                static T add(T a,T b) { return a + b; } /* X */
        };

        bool foo() {
                return Test<bool>::add(true,false); /* Y */
        };
the compiler actually complains about line /*X*/ which is absolutely 
correct, instead of telling the user that Test simply should not be 
instatiated with bool. Now if Test is somewhere deep within a library, the 
application programmer may get a huge bunch of error messages looking like 
a bug somewhere in the library, even though, the actual error was simply 
the wrong instatiation of a template.

Solution to this would be something like interfaces in D, specifying a set 
of capabilities of a type (be it a class or a predefined type), and the 
possibility to restrict parameters in a template definition to such an 
interface.
-------------------------

Now, this was just a rough sketch of what I found to be missing in D making 
it seriously fall back behind C++. It is nothing about philosophy or 
far-fetched theory, but just plain experience after many hours of digging 
into the depths of C++ templates.

Really bringing anything of this power into D would probably mean a redesign 
of large parts of the template and interface mechanism. It would also mean 
quite a bit of research and genious in language design. The mechanisms of 
expression templates are still quite new and much work is yet to be done to 
really understand the basic principles behind it.

Anyhow: unless this power is somehow carried over from C++, the language D 
can not seriously aim at measuring up with its ancestor.

Anyone interested in that whole topic, best start reading at
        http://www.oonumerics.org
perhaps starting out on blitz++ for the moment.
(I've done my own, smaller and simpler library, but it's hardly documented 
at all, so it is not yet a good starting point...)

Ciao,
Nobbi
Jan 15 2003
next sibling parent reply Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
I guess, my remark directly collides with the message "C and/or C++ in D" by 
Ben Woodhead from yesterday, therefore an additional remark:

Everything I mentioned, is, of course somehow possible to be done in D. The 
one crucial point simply is PERFORMANCE. What makes templates in C++ such a 
powerful tool in C++ is not, that they allow stuff impossible before. They 
do not even make life any more comfortable (quite in the contrary, they 
make life awfully complicated!!) Anyhow:

        They allow much of the work to be done at compile time!

I you don't want to worry about performance, simply ignore this whole topic.

Anyhow, in numerical computation, where performance often is one of the most 
crucial goals, expression templates seem to be the only way so far to allow 
the full expressiveness of object orientated languages without a huge 
performance penalty. Thousands of programmers in the numerical field still 
use Fortran 77 simply because of its unbeaten performance and it was not 
until the discovery of expression templates, that C++ could close up with 
that speed.

Anyhow: the suggestion of allowing to restrict template parameter types is 
probably independant of the other extensions, and I would seriously advise 
the language designers to consider this unless they want to make using 
template libraries a pain to anyone.

Ciao,
Nobbi
Jan 15 2003
parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b03ehf$2muu$1 digitaldaemon.com>, Norbert Nemec says...
I guess, my remark directly collides with the message "C and/or C++ in D" by 
Ben Woodhead from yesterday, therefore an additional remark:

Everything I mentioned, is, of course somehow possible to be done in D. The 
one crucial point simply is PERFORMANCE. What makes templates in C++ such a 
powerful tool in C++ is not, that they allow stuff impossible before. They 
do not even make life any more comfortable (quite in the contrary, they 
make life awfully complicated!!) Anyhow:

        They allow much of the work to be done at compile time!

I you don't want to worry about performance, simply ignore this whole topic.

Anyhow, in numerical computation, where performance often is one of the most 
crucial goals, expression templates seem to be the only way so far to allow 
the full expressiveness of object orientated languages without a huge 
performance penalty. Thousands of programmers in the numerical field still 
use Fortran 77 simply because of its unbeaten performance and it was not 
until the discovery of expression templates, that C++ could close up with 
that speed.

Anyhow: the suggestion of allowing to restrict template parameter types is 
probably independant of the other extensions, and I would seriously advise 
the language designers to consider this unless they want to make using 
template libraries a pain to anyone.

Ciao,
Nobbi
Hi, Expression templates aren't the only way of achieving performance in "correct" OO systems. In a good type system we can do more agressive inlining of operations, reduce the need for dynamic dispatch, do strictness analysis to ignore partial unnecessary results, do loop unrolling, etc.. All of these are good in every piece of code, not just in some particular mechanism. The problem with expression templates is that they require someone (the library writer) to know how to write code with optimization hints. In C++ template syntax is almost a language of its own. In Common Lisp macro expansion (which can do anything expression templates do and more) gives you similar performance, but the syntax is much more similar to Common Lisp. Scheme also provides a expressive and simple to use macro system. Best regards, Daniel Yokomiso.
Jan 16 2003
parent reply Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Daniel Yokomiso wrote:
 Hi,
 
 Expression templates aren't the only way of achieving performance in
 "correct" OO systems. In a good type system we can do more agressive
 inlining of operations, reduce the need for dynamic dispatch, do
 strictness analysis to ignore partial unnecessary results, do loop
 unrolling, etc.. All of these are good in every piece of code, not just in
 some particular mechanism. The problem with expression templates is that
 they require someone (the library writer) to know how to write code with
 optimization hints. In C++ template syntax is almost a language of its
 own. In Common Lisp macro expansion (which can do anything expression
 templates do and more) gives you similar performance, but the syntax is
 much more similar to Common Lisp. Scheme also provides a expressive and
 simple to use macro system.
Very true. Al these parts have to play together. As far as I can see it, the main advantage of expression templates is, just as you say, that C++ templates are a language on their own, allowing a library author to do all kinds of optimizations and complex decisions at compile time. The only use for them is in heavily optimized libraries - otherwise the effort for writing them will never be justified. Anyhow, in the quest for performance one always has to consider all the bottlenecks, and in the main field of usage for expression templates of C++ - i.e. array calculations - one of the main bottlenecks is the need for temporary copies. And this can only be solved by either implementing far more advanced array manipulations in D directly or give the library authors the tools necessary to do their best. Ciao, Nobbi
Jan 17 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
escreveu na mensagem news:b08ums$2p3a$1 digitaldaemon.com...
 Daniel Yokomiso wrote:
 Hi,

 Expression templates aren't the only way of achieving performance in
 "correct" OO systems. In a good type system we can do more agressive
 inlining of operations, reduce the need for dynamic dispatch, do
 strictness analysis to ignore partial unnecessary results, do loop
 unrolling, etc.. All of these are good in every piece of code, not just
in
 some particular mechanism. The problem with expression templates is that
 they require someone (the library writer) to know how to write code with
 optimization hints. In C++ template syntax is almost a language of its
 own. In Common Lisp macro expansion (which can do anything expression
 templates do and more) gives you similar performance, but the syntax is
 much more similar to Common Lisp. Scheme also provides a expressive and
 simple to use macro system.
Very true. Al these parts have to play together. As far as I can see it,
the
 main advantage of expression templates is, just as you say, that C++
 templates are a language on their own, allowing a library author to do all
 kinds of optimizations and complex decisions at compile time. The only use
 for them is in heavily optimized libraries - otherwise the effort for
 writing them will never be justified.

 Anyhow, in the quest for performance one always has to consider all the
 bottlenecks, and in the main field of usage for expression templates of
C++
 - i.e. array calculations - one of the main bottlenecks is the need for
 temporary copies. And this can only be solved by either implementing far
 more advanced array manipulations in D directly or give the library
authors
 the tools necessary to do their best.

 Ciao,
 Nobbi
We can add more powerful array operations if they became safer: http://www.sys.uea.ac.uk/~jrwg/Sisal/ This may solve the problems Expression Templates try to solve... --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003
Jan 17 2003
parent reply Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Daniel Yokomiso wrote:
     We can add more powerful array operations if they became safer:
 http://www.sys.uea.ac.uk/~jrwg/Sisal/ This may solve the problems
 Expression Templates try to solve...
You may also take a look at SAC (Single Assignment C) at http://www.informatik.uni-kiel.de/~sacbase/ which claims to the the official successor of Sisal. Anyway: Both languages are tailored towards high-performance numerical computing. No way to even consider taking D, which is explicitely designed to be a general purpose language in that direction. And just trying to pick bits from them will not buy us much.
Jan 20 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
escreveu na mensagem news:b0h0gs$159b$1 digitaldaemon.com...
 Daniel Yokomiso wrote:
     We can add more powerful array operations if they became safer:
 http://www.sys.uea.ac.uk/~jrwg/Sisal/ This may solve the problems
 Expression Templates try to solve...
You may also take a look at SAC (Single Assignment C) at http://www.informatik.uni-kiel.de/~sacbase/ which claims to the the official successor of Sisal. Anyway: Both languages are tailored towards high-performance numerical computing. No way to even consider taking D, which is explicitely designed to be a general purpose language in that direction. And just trying to pick bits from them will not buy us much.
SAC is also very nice too. IMO their array semantics could be extended to D without changing much of D's nature as general purpose programming language. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003
Jan 20 2003
prev sibling next sibling parent reply Theodore Reed <rizen surreality.us> writes:
On Wed, 15 Jan 2003 11:34:14 +0100
Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
wrote:

 * Templated functions - allowing stuff like:
 
         template <typename T>
         T special_addition(T a,T b) { ... }
 
 i.e. a function that takes two arguments of an arbitrary -- but
 identical -- type. Of course, the concept goes far beyond that and is
 absolutely indispensible in many cases.
I thought this was possible: template special (T) { T addition(T a, T b) { ... } } From what I under stand, there isn't anything you can't templatize, although your int example is interesting. I didn't even know C++ templates could do that. -- Theodore Reed (rizen/bancus) -==- http://www.surreality.us/ ~OpenPGP Signed/Encrypted Mail Preferred; Finger me for my public key!~ "Those who hammer their guns into plowshares will plow for those who do not." -- Thomas Jefferson
Jan 15 2003
parent Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Theodore Reed wrote:

 On Wed, 15 Jan 2003 11:34:14 +0100
 Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
 wrote:
 
 * Templated functions - allowing stuff like:
 
         template <typename T>
         T special_addition(T a,T b) { ... }
 
 i.e. a function that takes two arguments of an arbitrary -- but
 identical -- type. Of course, the concept goes far beyond that and is
 absolutely indispensible in many cases.
I thought this was possible: template special (T) { T addition(T a, T b) { ... } } From what I under stand, there isn't anything you can't templatize, although your int example is interesting. I didn't even know C++ templates could do that.
OK, but as I understand it, this needs to be called like: x = special(int).addition(3,5); whereas in C++, a call to addition(3,5) does implicit instatiation. Don't know, though, whether that would be a fundamental problem.
Jan 17 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
Comments embedded...

"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> wrote
in message news:b03d7n$2m9r$1 digitaldaemon.com...
 Hi there,

 I've just recently come upon the D language and was captured right away by
 it. Of all those programming languages I've found over the years, this
 definitely is one of the most promising!

 Anyway, the template mechanism has a number of deficiencies that makes it
 drop far behind that of C++. To those, who have never worked with stuff
 like the "expression template" method, this will look like minor details,
 but after implementing my own matrix library in C++ using that method, I
 definitely have come to realize the real power that lies behind the
 template concept in C++.

 Two examples of what is possible in C++, which I could not find in D:

 -------------------------
 * Templated functions - allowing stuff like:

         template <typename T>
         T special_addition(T a,T b) { ... }

 i.e. a function that takes two arguments of an arbitrary -- but
identical --
 type. Of course, the concept goes far beyond that and is absolutely
 indispensible in many cases.
This does work in D, as Theodore's example shows.
 -------------------------
 * Integers as template arguments:

         template <int N>
         class Vector {
                 double data[N];
         };

 making Vector<2> a different type than Vector<3>, allowing stuff like
direct
 vector or matrix manipulations via operators with complete type checking.
 (Going far beyond the simple possibilities of direct array manipulations
in
 D.)
This is probably going to have to be added to D. Nobody seems to like the alternative mechanism I proposed <g>.
 -------------------------
 The one thing that I dislike most about C++ templates, and which has been
 carried over to D as well, is, that template parameters are not typed.
I.e.
 if I have:
         template <typename T>
         class Test {
                 static T add(T a,T b) { return a + b; } /* X */
         };

         bool foo() {
                 return Test<bool>::add(true,false); /* Y */
         };
 the compiler actually complains about line /*X*/ which is absolutely
 correct, instead of telling the user that Test simply should not be
 instatiated with bool. Now if Test is somewhere deep within a library, the
 application programmer may get a huge bunch of error messages looking like
 a bug somewhere in the library, even though, the actual error was simply
 the wrong instatiation of a template.

 Solution to this would be something like interfaces in D, specifying a set
 of capabilities of a type (be it a class or a predefined type), and the
 possibility to restrict parameters in a template definition to such an
 interface.
 -------------------------
A good point. Error messages are always a pain with templates.
 Now, this was just a rough sketch of what I found to be missing in D
making
 it seriously fall back behind C++. It is nothing about philosophy or
 far-fetched theory, but just plain experience after many hours of digging
 into the depths of C++ templates.

 Really bringing anything of this power into D would probably mean a
redesign
 of large parts of the template and interface mechanism. It would also mean
 quite a bit of research and genious in language design. The mechanisms of
 expression templates are still quite new and much work is yet to be done
to
 really understand the basic principles behind it.

 Anyhow: unless this power is somehow carried over from C++, the language D
 can not seriously aim at measuring up with its ancestor.

 Anyone interested in that whole topic, best start reading at
         http://www.oonumerics.org
 perhaps starting out on blitz++ for the moment.
 (I've done my own, smaller and simpler library, but it's hardly documented
 at all, so it is not yet a good starting point...)

 Ciao,
 Nobbi
Jan 15 2003
next sibling parent Ilya Minkov <midiclub 8ung.at> writes:
 
 This is probably going to have to be added to D. Nobody seems to like the
 alternative mechanism I proposed <g>.
 
I'm sorry, i've searched through a bit but was unable to find it.
Jan 15 2003
prev sibling parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b04fq8$8t8$1 digitaldaemon.com>, Walter says...

[snip]

 -------------------------
 * Integers as template arguments:

         template <int N>
         class Vector {
                 double data[N];
         };

 making Vector<2> a different type than Vector<3>, allowing stuff like
direct
 vector or matrix manipulations via operators with complete type checking.
 (Going far beyond the simple possibilities of direct array manipulations
in
 D.)
This is probably going to have to be added to D. Nobody seems to like the alternative mechanism I proposed <g>.
[snip] Hi, I'm glad you're considering adding this to the language. Which kind of value parameters will be possible: just integers or any kind of value? Also there's another problem with current template syntax. We can't define templates which define templatized methods. E.g. a List(T) class with a method proposal allows definition of generic classes with generic methods, and you have to instantiate the generic method when you use it, not when you instantiate the generic class. This, together with integer template parameters will allow D to have type-safe unit classes for scientific programming: // Using CGS unit system public template class Unit(int C, int G, int S) { private double _value; public this(double value) { this._value = value; } public double value() { return this._value; } public Unit(C, G, S) mul(int other) { return new Unit(C, G, S)(value() * other); } public template Unit(C - X, G - Y, S - Z) div(Unit(X, Y, Z) other) { return new Unit(C - X, G - Y, S - Z)(value() / other.value()); } } alias Unit(1, 0, 0) Length; alias Unit(0, 1, 0) Mass; alias Unit(0, 0, 1) Time; alias Unit(1, 0, -1) Speed; alias Unit(2, 1, 2) Energy; const Length metre = new Length(100); const Length second = new Time(1); const Length kilogram = new Mass(1000); const Speed c = 299792458 * metre / second; Mass m = 100 * kilogram; Energy e; e = m * c * c; Nice isn't it? Some issues about invalid instantiation can happen if the code uses variables to define dimensions, but I think limiting dimensions to be constant isn't a big problem. I don't think the compiler complexity is a burden when we compare it to the benefits it brings. Best regards, Daniel Yokomiso.
Jan 16 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b06sg3$1m3l$1 digitaldaemon.com...
 I'm glad you're considering adding this to the language. Which kind of
value
 parameters will be possible: just integers or any kind of value?
Probably just integer constants. I like to be conservative on adding these kinds of things until a real need is clear.
 Also there's another problem with current template syntax. We can't define
 templates which define templatized methods. E.g. a List(T) class with a
method
 List(U) map(U (*operation)(T)). This is a very good thing to have.
I don't understand.

 proposal allows definition of generic classes with generic methods, and
you have
 to instantiate the generic method when you use it, not when you
instantiate the
 generic class. This, together with integer template parameters will allow
D to
 have type-safe unit classes for scientific programming:

 // Using CGS unit system
 public template class Unit(int C, int G, int S) {
 private double _value;
 public this(double value) {
 this._value = value;
 }
 public double value() {
 return this._value;
 }
 public Unit(C, G, S) mul(int other) {
 return new Unit(C, G, S)(value() * other);
 }
 public template Unit(C - X, G - Y, S - Z) div(Unit(X, Y, Z) other) {
 return new Unit(C - X, G - Y, S - Z)(value() / other.value());
 }
 }

 alias Unit(1, 0, 0) Length;
 alias Unit(0, 1, 0) Mass;
 alias Unit(0, 0, 1) Time;
 alias Unit(1, 0, -1) Speed;
 alias Unit(2, 1, 2) Energy;

 const Length metre = new Length(100);
 const Length second = new Time(1);
 const Length kilogram = new Mass(1000);
 const Speed c = 299792458 * metre / second;

 Mass m = 100 * kilogram;
 Energy e;

 e = m * c * c;

 Nice isn't it? Some issues about invalid instantiation can happen if the
code
 uses variables to define dimensions, but I think limiting dimensions to be
 constant isn't a big problem. I don't think the compiler complexity is a
burden
 when we compare it to the benefits it brings.

 Best regards,
 Daniel Yokomiso.
Jan 18 2003
next sibling parent Norbert Nemec <Nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Walter wrote:

 "Daniel Yokomiso" <Daniel_member pathlink.com> wrote:
 I'm glad you're considering adding this to the language. Which kind of
 value parameters will be possible: just integers or any kind of value?
Probably just integer constants. I like to be conservative on adding these kinds of things until a real need is clear.
Hopefully bits and enums as well?
Jan 18 2003
prev sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:b0b9dm$165s$1 digitaldaemon.com...
 "Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
 news:b06sg3$1m3l$1 digitaldaemon.com...
 I'm glad you're considering adding this to the language. Which kind of
value
 parameters will be possible: just integers or any kind of value?
Probably just integer constants. I like to be conservative on adding these kinds of things until a real need is clear.
 Also there's another problem with current template syntax. We can't
define
 templates which define templatized methods. E.g. a List(T) class with a
method
 List(U) map(U (*operation)(T)). This is a very good thing to have.
I don't understand.
We define a template for a generic list class: template TList(T) { class List { T first(); List rest(); T get(int index); void set(int index, T value); int length(); List slice(int start, int afterEnd); List filter(boolean (*predicate)(T)); } } With all needed operations. One idiom from functional programming is using a map operation to transverse data-structures using higher-order functions: Address getAddress(Employee emp) { return emp.address; } instance TList(Employee).List employees = ...; instance TList(Address).List addresses = employees.map(&getAddress); and map has a body that looks like (types ommited): map(*operation) { List result = new List(this.length()); for (int i = 0; i < this.length(); i++) { result.set(i, operation(get(i))); } return result; } If *operation is function that maps values of one type into another type. It's a higher-order function, that means a function that has other functions as parameters. But map must be generic beyond the scope of initial template instantiation, because we can instantiate a list template of ints and use mapping functions that gives lists of doubles (e.g. applying sqrt to all ints), lists of char[] (e.g. string forms of numbers) or even lists of ints (e.g. negated values). This application of functions that are templatized and introduce a second level of parametrization is useful in lots of different areas, a map function in a list type is one of the simplest form of using it. Today we have to write another template: template TMap(T, U) { instance TList(U).List ListU; instance TList(T).List ListT; ListU map(ListT list, U (*operation)(T)) { ListU result = new ListU(this.length()); for (int i = 0; i < list.length(); i++) { result.set(i, operation(list.get(i))); } return result; } } And users must always explicitly instantiate the templates and use tmap.map(list, op) instead of a simpler form list.map(op). There are functions that may be parametrized with more than one extra type parameter, so we end with lots of explicit templates. Also the additional templates must have a way to efficiently access the data from the list type, either using an external iterator, or something like that, where a generic method can access the internals of the class without penalty. specialization. Any statically typed functional language has it too. In Java generic methods look like this: // snippet from last proposal class Seq<A> { <B> Seq<Pair<A,B>> zip(Seq<B> that) { if (this.isEmpty() || that.isEmpty()) { return new Seq<Pair<A,B>>(); } else { return new Seq<Pair<A,B>>( new Pair<A,B>(this.head, that.head), this.tail.<B>zip(that.tail)); } } } where Seq is a sequence type, and zip takes two sequences and return a sequence of pairs taken from each. I think we need this kind of functionality, or else we will be forced to written additional templates for each possible combination of parametrized methods. Also the trick I used in the last a email of making type-safe unit types (combining integer parameters and generic methods) won't be available :-( Best regards, Daniel Yokomiso. "Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us." - Bill Watterson --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003
Jan 18 2003
prev sibling parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
Hi, 

Answers embedded.

In article <b03d7n$2m9r$1 digitaldaemon.com>, Norbert Nemec says...
Hi there,

I've just recently come upon the D language and was captured right away by 
it. Of all those programming languages I've found over the years, this 
definitely is one of the most promising!

Anyway, the template mechanism has a number of deficiencies that makes it 
drop far behind that of C++. To those, who have never worked with stuff 
like the "expression template" method, this will look like minor details, 
but after implementing my own matrix library in C++ using that method, I 
definitely have come to realize the real power that lies behind the 
template concept in C++.

Two examples of what is possible in C++, which I could not find in D:

-------------------------
* Templated functions - allowing stuff like:

        template <typename T>
        T special_addition(T a,T b) { ... }

i.e. a function that takes two arguments of an arbitrary -- but identical -- 
type. Of course, the concept goes far beyond that and is absolutely 
indispensible in many cases.
As others pointed out this is possible in D: template TAddition(T) { T special_addition(T a,T b) { ... } } But we need to name the template.So usually D templates pack a set of related functions.
-------------------------
* Integers as template arguments:

        template <int N>
        class Vector {
                double data[N];
        };

making Vector<2> a different type than Vector<3>, allowing stuff like direct 
vector or matrix manipulations via operators with complete type checking. 
(Going far beyond the simple possibilities of direct array manipulations in 
D.)
As Walter pointed out this will get in D. That is a Good Thing :-)
-------------------------
The one thing that I dislike most about C++ templates, and which has been 
carried over to D as well, is, that template parameters are not typed. I.e.
if I have:
        template <typename T>
        class Test {
                static T add(T a,T b) { return a + b; } /* X */
        };

        bool foo() {
                return Test<bool>::add(true,false); /* Y */
        };
the compiler actually complains about line /*X*/ which is absolutely 
correct, instead of telling the user that Test simply should not be 
instatiated with bool. Now if Test is somewhere deep within a library, the 
application programmer may get a huge bunch of error messages looking like 
a bug somewhere in the library, even though, the actual error was simply 
the wrong instatiation of a template.

Solution to this would be something like interfaces in D, specifying a set 
of capabilities of a type (be it a class or a predefined type), and the 
possibility to restrict parameters in a template definition to such an 
interface.
-------------------------
If you restrict yourself to classes, you can restrict the type parameters: template TSort(T : Comparable) { } where Comparable is a type or class. AFAIK it's valid D code, if not is should ;-) . There's some info at http://www.digitalmars.com/d/template.html under Argument Deduction section. I don't think there's any reason for the compiler to always complain about line /*X*/, instead of saying: Template instantiation at line /*Y*/ is invalid because of /*X*/ requirement in template body. Systems with type inference algorithms usually provide some intelligent error messages. There's also some papers about giving intelligent error messages in type inference algorithms.
Now, this was just a rough sketch of what I found to be missing in D making 
it seriously fall back behind C++. It is nothing about philosophy or 
far-fetched theory, but just plain experience after many hours of digging 
into the depths of C++ templates.

Really bringing anything of this power into D would probably mean a redesign 
of large parts of the template and interface mechanism. It would also mean 
quite a bit of research and genious in language design. The mechanisms of 
expression templates are still quite new and much work is yet to be done to 
really understand the basic principles behind it.

Anyhow: unless this power is somehow carried over from C++, the language D 
can not seriously aim at measuring up with its ancestor.
IIRC D's ancestor is C. C++ is just an older cousin ;-)
Anyone interested in that whole topic, best start reading at
        http://www.oonumerics.org
perhaps starting out on blitz++ for the moment.
(I've done my own, smaller and simpler library, but it's hardly documented 
at all, so it is not yet a good starting point...)

Ciao,
Nobbi
C++ template mechanism is very powerful, but almost impossible to get right. Walter writes C++ compiler writes since the beginning of C++, so he knows about the pitfalls of template mechanism. All these issues about template are causes of several threads in this newsgroup (check the archives where lots of people, including me, argue for a better template mechanism). Blitz++ does a very good usageof templates, I like particularly the tensor notation. But it carries a 750 page language standard behind it, defining the mechanism it uses. Walter wants something better, we just have to keep throwing him good ideas and critics. Best regards, Daniel Yokomiso.
Jan 16 2003
parent reply Norbert Nemec <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Daniel Yokomiso wrote:

 In article <b03d7n$2m9r$1 digitaldaemon.com>, Norbert Nemec says...
-------------------------
The one thing that I dislike most about C++ templates, and which has been
carried over to D as well, is, that template parameters are not typed.
I.e. if I have:
        template <typename T>
        class Test {
                static T add(T a,T b) { return a + b; } /* X */
        };

        bool foo() {
                return Test<bool>::add(true,false); /* Y */
        };
the compiler actually complains about line /*X*/ which is absolutely
correct, instead of telling the user that Test simply should not be
instatiated with bool. Now if Test is somewhere deep within a library, the
application programmer may get a huge bunch of error messages looking like
a bug somewhere in the library, even though, the actual error was simply
the wrong instatiation of a template.

Solution to this would be something like interfaces in D, specifying a set
of capabilities of a type (be it a class or a predefined type), and the
possibility to restrict parameters in a template definition to such an
interface.
If you restrict yourself to classes, you can restrict the type parameters: template TSort(T : Comparable) { } where Comparable is a type or class. AFAIK it's valid D code, if not is should ;-) .
I'm not sure whether that should really be the correct way to say it. Otherwise template X(T:T[]) {} would mean that T has to be a subtype of T[], which is complete nonsense. It is hard to name the actual meaning of the ":", but it definitely is not "subtype of". Actually, I don't have the slightest idea what would be better. Perhaps: template X(T:T < Comparable) {} as in Sather?
 I don't think there's any reason for the compiler to always
 complain about line /*X*/, instead of saying: Template instantiation at
 line /*Y*/ is invalid because of /*X*/ requirement in template body.
 Systems with type inference algorithms usually provide some intelligent
 error messages. There's also some papers about giving intelligent error
 messages in type inference algorithms.
Problem is, that in C++ code (and in D code as well), one cannot even say where the error lies. Did the library author do something illegal with the argument, or did the application programmer do a wrong instatiation? As long as there is no way to specify what capabilities the parameter types are supposed to have, even the most intelligent compiler cannot say more than: /*Y*/ seems to be wrong because of /*X*/, or even more nested error messages. In a case of 10 nested instantiations, the actual error might be located at any level. And what it worse: there is no way to completely test the compilability of a template without doing all possible instantiations.
 C++ template mechanism is very powerful, but almost impossible to get
 right. Walter writes C++ compiler writes since the beginning of C++, so he
 knows about the pitfalls of template mechanism. All these issues about
 template are causes of several threads in this newsgroup (check the
 archives where lots of people, including me, argue for a better template
 mechanism). Blitz++ does a very good usageof templates, I like
 particularly the tensor notation. But it carries a 750 page language
 standard behind it, defining the mechanism it uses. Walter wants something
 better, we just have to keep throwing him good ideas and critics.
Nothing to say against that! Probably, the whole power of the C++ template mechanism was never actually planned. Actually, the fact that it hides a complete language on its own was even found by accident. And up to now, I guess nobody has really pinned down what the details are that make it so powerful. Guess it will take a good portion of genious to extract that part without carrying over all the drawbacks... Ciao, Nobbi
Jan 17 2003
next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
escreveu na mensagem news:b08u26$2orh$1 digitaldaemon.com...
 Daniel Yokomiso wrote:

 In article <b03d7n$2m9r$1 digitaldaemon.com>, Norbert Nemec says...
-------------------------
The one thing that I dislike most about C++ templates, and which has
been
carried over to D as well, is, that template parameters are not typed.
I.e. if I have:
        template <typename T>
        class Test {
                static T add(T a,T b) { return a + b; } /* X */
        };

        bool foo() {
                return Test<bool>::add(true,false); /* Y */
        };
the compiler actually complains about line /*X*/ which is absolutely
correct, instead of telling the user that Test simply should not be
instatiated with bool. Now if Test is somewhere deep within a library,
the
application programmer may get a huge bunch of error messages looking
like
a bug somewhere in the library, even though, the actual error was simply
the wrong instatiation of a template.

Solution to this would be something like interfaces in D, specifying a
set
of capabilities of a type (be it a class or a predefined type), and the
possibility to restrict parameters in a template definition to such an
interface.
If you restrict yourself to classes, you can restrict the type
parameters:
 template TSort(T : Comparable) {
 }

 where Comparable is a type or class. AFAIK it's valid D code, if not is
 should ;-) .
I'm not sure whether that should really be the correct way to say it. Otherwise template X(T:T[]) {} would mean that T has to be a subtype of T[], which is complete nonsense.
It
 is hard to name the actual meaning of the ":", but it definitely is not
 "subtype of". Actually, I don't have the slightest idea what would be
 better. Perhaps:
         template X(T:T < Comparable) {}
 as in Sather?
Maybe if we use the subtype operator <: from theoretical OO work. template X(T <: Comparable; U; V <: Somethingable, Otherthingable) {} with multiple constraints possible. Are multiple constraints possible in Sather? I don't remember reading about this in the docs, but I'm sure in Eiffel they aren't.
 I don't think there's any reason for the compiler to always
 complain about line /*X*/, instead of saying: Template instantiation at
 line /*Y*/ is invalid because of /*X*/ requirement in template body.
 Systems with type inference algorithms usually provide some intelligent
 error messages. There's also some papers about giving intelligent error
 messages in type inference algorithms.
Problem is, that in C++ code (and in D code as well), one cannot even say where the error lies. Did the library author do something illegal with the argument, or did the application programmer do a wrong instatiation? As long as there is no way to specify what capabilities the parameter types are supposed to have, even the most intelligent compiler cannot say more than: /*Y*/ seems to be wrong because of /*X*/, or even more nested error messages. In a case of 10 nested instantiations, the actual error might be located at any level. And what it worse: there is no way to completely test the compilability of
a
 template without doing all possible instantiations.
The way I see it, a template is always correct. The complete set of requirements that a type parameter must meet is in all the possible usages inside the template (all execution paths). So if the template requires your type to provide + & [] .connectToSQL() operations, it's your problem meeting this. At least until we can add operation interfaces. In current mechanisms the template determine a structural typing constraint a la OCaml methods on their parameters.
 C++ template mechanism is very powerful, but almost impossible to get
 right. Walter writes C++ compiler writes since the beginning of C++, so
he
 knows about the pitfalls of template mechanism. All these issues about
 template are causes of several threads in this newsgroup (check the
 archives where lots of people, including me, argue for a better template
 mechanism). Blitz++ does a very good usageof templates, I like
 particularly the tensor notation. But it carries a 750 page language
 standard behind it, defining the mechanism it uses. Walter wants
something
 better, we just have to keep throwing him good ideas and critics.
Nothing to say against that! Probably, the whole power of the C++ template mechanism was never actually planned. Actually, the fact that it hides a complete language on its own was even found by accident. And up to now, I guess nobody has really pinned down what the details are that make it so powerful. Guess it will take a good portion of genious to extract that
part
 without carrying over all the drawbacks...

 Ciao,
 Nobbi
Maybe if we ordinary folks think hard enough for sufficient time we can mimic geniality? ;-) Best regards, Daniel Yokomiso. "It is a bit embarrassing to have been concerned with the human problem all one's life and find at the end that one has no more to offer by way of advice than 'Try to be a little kinder'." - Aldous Huxley --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 11/1/2003
Jan 17 2003
next sibling parent reply Norbert Nemec <Nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Daniel Yokomiso wrote:
     Maybe if we use the subtype operator <: from theoretical OO work.
 
 
 template X(T <: Comparable; U; V <: Somethingable, Otherthingable) {}
 
 
 with multiple constraints possible.
 Are multiple constraints possible in Sather?
No, but you have multiple inheritance (with ingeniously simple mechanisms to avoid all the hassle of it) so you can just pull two interfaces together to a combined one.
     The way I see it, a template is always correct. The complete set of
 requirements that a type parameter must meet is in all the possible usages
 inside the template (all execution paths). So if the template requires
 your type to provide + & [] .connectToSQL() operations, it's your problem
 meeting this. At least until we can add operation interfaces. In current
 mechanisms the template determine a structural typing constraint a la
 OCaml methods on their parameters.
True, but the core of the problem really is, that you cannot specify those requirements in the interface of the template. That way, a template cannot really be separated into interface and implementation, but you (and the compiler as well) have to read the whole implementation to know the interface.
 Maybe if we ordinary folks think hard enough for sufficient time we can
 mimic geniality? ;-)
Dream on! Ingenious ideas have always suddenly sprung up from somewhere, and the hardest part always was to recognize them as such. There are probably tons of ingenious ideas hidden in the discussions of this newsgroup, but in the end it will be the responsibility of Walter to pick out the good ones. And that will always need some geniality on its own... :-)
Jan 18 2003
next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Norbert Nemec" <Nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
escreveu na mensagem news:b0bej0$18bu$1 digitaldaemon.com...
 Daniel Yokomiso wrote:
     Maybe if we use the subtype operator <: from theoretical OO work.


 template X(T <: Comparable; U; V <: Somethingable, Otherthingable) {}


 with multiple constraints possible.
 Are multiple constraints possible in Sather?
No, but you have multiple inheritance (with ingeniously simple mechanisms
to
 avoid all the hassle of it) so you can just pull two interfaces together
to
 a combined one.
Sather provide sub and super typing operator IIRC, but it can be used to redefine the inheritance hierarchy of two different set of classes? E.g. in library A there's a method that requires something of type NumericComparable that is both Numeric and Comparable. In library B exists class C that inherits from Numeric and Comparable, but not from NumericComparable. The user of these two libraries may say that C inherits from NumericComparable too?
     The way I see it, a template is always correct. The complete set of
 requirements that a type parameter must meet is in all the possible
usages
 inside the template (all execution paths). So if the template requires
 your type to provide + & [] .connectToSQL() operations, it's your
problem
 meeting this. At least until we can add operation interfaces. In current
 mechanisms the template determine a structural typing constraint a la
 OCaml methods on their parameters.
True, but the core of the problem really is, that you cannot specify those requirements in the interface of the template. That way, a template cannot really be separated into interface and implementation, but you (and the compiler as well) have to read the whole implementation to know the interface.
Or rely on the intelligent and informative error messages from the compiler ;-)
 Maybe if we ordinary folks think hard enough for sufficient time we can
 mimic geniality? ;-)
Dream on! Ingenious ideas have always suddenly sprung up from somewhere,
and
 the hardest part always was to recognize them as such. There are probably
 tons of ingenious ideas hidden in the discussions of this newsgroup, but
in
 the end it will be the responsibility of Walter to pick out the good ones.
 And that will always need some geniality on its own... :-)
That's why I keep reading posts from several different sources (e.g.: comp.lang.functional, comp.compilers) and download more papers than I can read. To improve my geniality skills ;-) "Norbert Nemec" <Nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> escreveu na mensagem news:b0bej0$18bu$1 digitaldaemon.com...
 Daniel Yokomiso wrote:
     Maybe if we use the subtype operator <: from theoretical OO work.


 template X(T <: Comparable; U; V <: Somethingable, Otherthingable) {}


 with multiple constraints possible.
 Are multiple constraints possible in Sather?
No, but you have multiple inheritance (with ingeniously simple mechanisms
to
 avoid all the hassle of it) so you can just pull two interfaces together
to
 a combined one.
Sather provide sub and super typing operator IIRC, but it can be used to redefine the inheritance hierarchy of two different set of classes? E.g. in library A there's a method that requires something of type NumericComparable that is both Numeric and Comparable. In library B exists class C that inherits from Numeric and Comparable, but not from NumericComparable. The user of these two libraries may say that C inherits from NumericComparable too?
     The way I see it, a template is always correct. The complete set of
 requirements that a type parameter must meet is in all the possible
usages
 inside the template (all execution paths). So if the template requires
 your type to provide + & [] .connectToSQL() operations, it's your
problem
 meeting this. At least until we can add operation interfaces. In current
 mechanisms the template determine a structural typing constraint a la
 OCaml methods on their parameters.
True, but the core of the problem really is, that you cannot specify those requirements in the interface of the template. That way, a template cannot really be separated into interface and implementation, but you (and the compiler as well) have to read the whole implementation to know the interface.
Or rely on the intelligent and informative error messages from the compiler ;-)
 Maybe if we ordinary folks think hard enough for sufficient time we can
 mimic geniality? ;-)
Dream on! Ingenious ideas have always suddenly sprung up from somewhere,
and
 the hardest part always was to recognize them as such. There are probably
 tons of ingenious ideas hidden in the discussions of this newsgroup, but
in
 the end it will be the responsibility of Walter to pick out the good ones.
 And that will always need some geniality on its own... :-)
That's why I keep reading posts from several different sources (e.g.: comp.lang.functional, comp.compilers) and download more papers than I can read. To improve my geniality skills ;-)
Jan 18 2003
parent Norbert Nemec <Nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> writes:
Daniel Yokomiso wrote:
 "Norbert Nemec" <Nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
 Daniel Yokomiso wrote:
     Maybe if we use the subtype operator <: from theoretical OO work.


 template X(T <: Comparable; U; V <: Somethingable, Otherthingable) {}


 with multiple constraints possible.
 Are multiple constraints possible in Sather?
No, but you have multiple inheritance (with ingeniously simple mechanisms to avoid all the hassle of it) so you can just pull two interfaces together to a combined one.
Sather provide sub and super typing operator IIRC, but it can be used to redefine the inheritance hierarchy of two different set of classes? E.g. in library A there's a method that requires something of type NumericComparable that is both Numeric and Comparable. In library B exists class C that inherits from Numeric and Comparable, but not from NumericComparable. The user of these two libraries may say that C inherits from NumericComparable too?
No, but through post-hoc supertyping, he can define MyNumericComparable as a subtype of Numeric and Comparable and a Supertype of C. Anyhow, at that point, the whole class system gets too different from D to be discussed on this list fruitfully. Ciao, Nobbi
Jan 18 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Norbert Nemec" <Nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> wrote
in message news:b0bej0$18bu$1 digitaldaemon.com...
 Dream on! Ingenious ideas have always suddenly sprung up from somewhere,
and
 the hardest part always was to recognize them as such. There are probably
 tons of ingenious ideas hidden in the discussions of this newsgroup,
You're right about that, and I've adopted more than a few into D.
 but in
 the end it will be the responsibility of Walter to pick out the good ones.
My worry is that some adverse combinations of features of D will box it into a corner.
 And that will always need some geniality on its own... :-)
Saying no to someone's proposed feature they expended a lot of thought and effort into presenting is really the hardest part of my task. I know how they feel, as not one of my proposed changes ever was adopted by the C++ standards people <g>. (And hence, the genesis of D.)
Feb 15 2003
prev sibling parent reply Marcelo Fontenele S Santos <msantos pobox.com> writes:
Daniel Yokomiso wrote:
 
     The way I see it, a template is always correct. The complete set of
 requirements that a type parameter must meet is in all the possible usages
 inside the template (all execution paths). So if the template requires your
 type to provide + & [] .connectToSQL() operations, it's your problem meeting
 this. At least until we can add operation interfaces. In current mechanisms
 the template determine a structural typing constraint a la OCaml methods on
 their parameters.
 
Hi, In C++ templates there are concepts like iterator, forward_iterator, allocator, etc. They exist, but are not enforced by the language. Maybe in D we could use interfaces to enforce the concepts needed by the templates. And explicitly tell the compiler the concepts/interfaces a certain template type expects. I think it would make error detection much simpler. OT: Just to put my 2 cents, I prefer the proposed template notation using the $ to specify the generic part. -- Marcelo Fontenele S Santos <msantos pobox.com>
Feb 04 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Marcelo Fontenele S Santos wrote:
 Daniel Yokomiso wrote:
 
     The way I see it, a template is always correct. The complete set of
 requirements that a type parameter must meet is in all the possible 
 usages
 inside the template (all execution paths). So if the template requires 
 your
 type to provide + & [] .connectToSQL() operations, it's your problem 
 meeting
 this. At least until we can add operation interfaces. In current 
 mechanisms
 the template determine a structural typing constraint a la OCaml 
 methods on
 their parameters.
Hi, In C++ templates there are concepts like iterator, forward_iterator, allocator, etc. They exist, but are not enforced by the language. Maybe in D we could use interfaces to enforce the concepts needed by the templates. And explicitly tell the compiler the concepts/interfaces a certain template type expects. I think it would make error detection much simpler.
Predicate types - or type constraints - are supported by most generic systems that I've seen. One way they could be in D is like this: predicate TComparable ($T) { $T a, b; a < b; } A type is TComparable if it can be inserted in this block statement and pass the semantic phase. In use it would be, say: $T min ($T first, $T [] rest...) predicate TComparable ($T) body { foreach ( ; i in rest; ) { if (i < first) first = i; } return first; } This is more powerful than Eiffel's syntax because you can include multiple arguments to the predicate and fail a set of types because of an incompatible interaction. It could even include type arguments to act as specialisations. So for example: predicate TMatrix4x4 (int $Rows, int $Cols) { assert ($Rows == 4 && $Cols == 4); } struct Matrix ($T, int $Rows, int $Cols) predicate TMatrix4x4 ($Rows, $Cols) body { /* Various SIMD functionality. */ }
Feb 04 2003
parent Marcelo Fontenele S Santos <msantos pobox.com> writes:
Burton Radons wrote:
 Predicate types - or type constraints - are supported by most generic 
 systems that I've seen.  One way they could be in D is like this:
 
    predicate TComparable ($T)
    {
        $T a, b;
 
        a < b;
    }
 
 A type is TComparable if it can be inserted in this block statement and 
 pass the semantic phase.  In use it would be, say:
 
    $T min ($T first, $T [] rest...)
    predicate TComparable ($T)
    body
    {
        foreach ( ; i in rest; )
        {
            if (i < first)
                first = i;
        }
        return first;
    }
 
The problem I see with this approach is that you can add something to the body that is not tested in the predicate. So it would pass the test but could fail to instantiate for a specific type. Before I give my sugestion I must say that I don't know anything about compilers. So anything I say can be impossible or unnecessary. My sugestion is to use template interfaces: interface TComparable($T) // $T is the self type { int cmp( $T rhs ); } And maybe a syntax like: $T min ($T first, $T [] rest...) use($T) TComparable { ... } This means $T must implement that interface and in the body it would only allow the use of $T vars through interface defined calls. $T search( $T first1, $T last1, $U first2, $U last2 ) use($T) TForwardIterator, use($U) TForwardIterator { ... } Extending the above example to be more restrictive we could do: interface TComparable( $T, $U ) { // $T is self type int cmp( $U rhs ); // compare itself with another type } $T search( $T first1, $T last1, $U first2, $U last2 ) use($T) TForwardIterator, use($U) TForwardIterator, use(*$T, *$U) TComparable // TForwardIterator must provide a * op { ... } The problem I see is with built-in types. I don't know how the operators relate to the overloadable methods. Should this work? int i = 0; if ( i.cmp( 0 ) == 0 ) { printf("ok\n"); } It doesn't compile in dli-0.1.2. I also don't know how to check if they implement an interface. For it to work, interfaces should not need to be defined in the class (they could be to detect errors). They would have to be checked during compilation. class X : TComparable { // ok X must implement cmp int cmp( X x ); } class Y { int cmp( Y y ); } TComparable c = (TComparable) Y; // ok Y implements cmp So it would work for built-ins. int i = 0; TComparable c = (TComparable) i; // ok int implements cmp Sugestions? Opinions? -- Marcelo Fontenele S Santos <msantos pobox.com>
Feb 05 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> wrote
in message news:b08u26$2orh$1 digitaldaemon.com...
 Probably, the whole power of the C++ template
 mechanism was never actually planned.
It wasn't. I remember Bjarne's original template paper, and conversations with him about it. The original scheme was not much more than a glorified macro substitution scheme, and few thought it would be hard to implement <g>. There was no hint it would evolve into what it is today.
 Actually, the fact that it hides a
 complete language on its own was even found by accident.
Yes.
 And up to now, I
 guess nobody has really pinned down what the details are that make it so
 powerful. Guess it will take a good portion of genious to extract that
part
 without carrying over all the drawbacks...
I think the partial specialization is the real source of the power of templates.
Feb 15 2003