http://prismwiki.codegear.com/en/Generic_Variance

On the C++ part, I think it should be noted that, while most compilers simply reparse the substituted template definition when instantiating it, the standard actually demands "two-phase name lookup", which requires that the template be parsed as far as possible, and all expressions which don’t depend on the template arguments be checked syntactically and semantically when the template definition is first encountered. I think only EDG’s frontend (which is being used for Intel’s and Comeau’s C++ compiler) implements this correctly.

I understand that you’re concentrating on the technical implementation bits, but especially when mentioning concepts, I think that one major flaw of C++ templates is worth mentioning: constraint errors being reported as errors in the actual template. This was one of the major issues which Concepts were meant to address. As an example, imagine calling the std::sort algorithm, which requires you to pass random-access iterators:

// -----
std::vector <int> myInts (42);
std::sort (myInts.begin (), myInts.end (), std::less <int> ());
// -----

This works fine - the code instantiates a vector of ints, sets the size to 42 and then sorts them; to access a specific element in the array, it uses direct index access via the first iterator, i.e. myints.begin()[n]. Now, the cool things about iterators is that their handling is independent from the type of the container they belong to, similar to IComparable/IEnumerable, but with all the polymorphism being resolved at compile time. So for most algorithms that only require uni- or bidirectional iterators, changing the std::vector to a std::list would just work fine. But as I said, std::sort() requires random access iterators (which provide an overload for the [] operator), so calling std::sort() with iterators pointing to a linked list will fail. Of course the error is in the user’s code: calling std::sort() on iterators without random access isn’t supposed to work. But the sad thing is that the compiler won’t tell you: e.g., all you get from BCC is two errors in system headers (sorry for German language):

// —–
Fehler E2093 E:\Programme\Weaver\\Include\dinkumware\algorithm 2220: ‘operator-’ ist im Typ ‘list<int,allocator >::iterator’ für Argumente desselben Typs nicht implementiert in Funktion std::void sort<list<int,allocator >::iterator,less >(list<int,allocator >::iterator,list<int,allocator >::iterator,less)
Fehler E2285 E:\Programme\Weaver\\Include\dinkumware\algorithm 2220: Keine Übereinstimmung für ‘_Sort(list<int,allocator >::iterator,list<int,allocator >::iterator,undefined,less)’ gefunden in Funktion void sort<list<int,allocator >::iterator,less >(list<int,allocator >::iterator,list<int,allocator >::iterator,less)
// —–

This is because std::sort() is a function template, and as such it’s just reparsed for this instantiation, but with above type substitution, the reparse causes an error - which of course occurs in the actual template code. Note that BCC is one of the well-behaving compilers WRT template error messages - with a little experience, you can see what happened in above messages, and with Extended Error Info turned on the compiler will even tell you about the file which the instantiation occurred in. But not all compilers are that easy to work with. Just look at the output EDG generates for this code (you can try it online on Dinkumware’s site at http://www.dinkumware.com/exam/default.aspx):

// -----
#include <algorithm>
#include <vector>
#include <list>

int main (void)
{
//std::vector <int> myInts (42);
std::list <int> myInts;
std::sort (myInts.begin (), myInts.end (), std::less <int> ());
}
// -----

I won’t quote the output here, for it’s 37 error messages spread over a total of 863 lines, all of which point to the system header std::sort() is defined in.

Also, while reading the bit on covariance and contravariance, though, I thought you should have mentioned Java there. While I think that Java’s generics are fundamentally crippled due to their use of type erasure (for the sake of JVM backward compatibility), they still handle covariance and contravariance nicely, something which I often miss in C++ and Delphi.

Response: Thank you very much, Moritz, this is a great comment! I’ve taken the liberty of formatting your source code and replacing the angle brackets; please let me know if I’ve missed anything. Great point about the error messages; I will update the article to include that (with the clarification in your second paragraph). I really appreciate all the thought you put into the comment! Regarding Java, I didn’t include it because, unlike the other languages which I did include, I consider the implementation to be essentially broken by design (for precisely the reason you mention). It would’ve been very interesting to include Scala, but I would need to understand it better to say anything intelligent on the subject.

A path paved with folly and edged with razors on one side and a precipitous cliff on the other, imho and ime. ymmv.

Response: I view it as very much like ASM. My wild guess is that the majority of Delphi developers don’t understand ASM. Yet all Delphi developers use routines written in ASM, every day, and in every program they write. Will you be a better Delphi developer if you do understand ASM? Yes, certainly; even if you never write in ASM routine yourself, you will regularly debug through them. But can you get started and be a productive developer without learning ASM first? The evidence I’ve seen suggests yes.