Tja, ik ben niet onder de indruk. Het artikel vergelijkt bestaande features in C++ met mogelijke optimalisaties in .Net (eerste alinea : C++ genereert compile-time code, .Net runtime. C++ heeft geen reuse, .Net kan het wel hebben). 4 Jaar geleden demonstreerde Todd Velduizen van Indiana University al dat C++ templates geimplementeerd kunnen worden zoals de .Net templates blijkbaar ergens in de toekomst geimplementeerd kunnen worden.
Bovendien zijn .Net templates bij design beperkt. Zoals de auteur schrijft,
Of all the fringe benefits of run-time type expansion, my favorite is a somewhat subtle one. Generic code is limited to operations that are certain to work for any constructed instantiation of the type. The side effect of this restriction is that CLR generics are more understandable and usable than their C++ template counterparts.
Dit is bijzonder ironisch, als je het gevloek hebt gehoord in de C++ gemeenschap wat oprees over het gemis van precies dit feature in MSVC6. In MSVC7 zat partial specialization er al in. Waarom is dit feature zo essentieel? Iedereen die recursie heeft gebruikt weet dat je een stop-conditie moet hebben. In een recursief template doe je dat via een specialisatie. Concreet is dit relevant in multi-dimensionale array containers. Een subscript operator[] zal een lager-dimensionale array opleveren. De uitzondering is de 1-dimensionale array, waar een specialisatie ervoor zorgt dat je het daadwerkelijke element krijgt. MSVC6 heeft bij mij al eens een ICE opgeleverd nadat de instantiatie van een -65532-dimensionale array faalde (ik propeerde een 3D array class uit).
Een andere beperking die bewijst dat er niet hard naar bestaande C++ praktijk is gekeken is de beperking dat elk template voor elk argument geinstantieerd moet kunnen worden. Dit maakt policies volledig onmogelijk. Policies zijn classes die als template-argument worden gebruikt. Een voorbeeld is een string template, die als policy een ISO_8859_1 policy of een UTF_8 policy meekrijgt. Zo'n string class kan op die manier het aantal karakters tellen, of een uppercase algoritm implementeren. In .Net kan dit niet, omdat het legaal zou moeten zijn om een Integer als policy mee te geven.
Er wordt gesuggereerd dat constraints dit oplossen. Helaas, maar dat is een probleem. Constraints zijn Interface beperkingen op objecten, en policies zijn types. Een ander probleem is dat het niet mogelijk is om te specialiseren op basis van constraint. Als ik een find() functie wil implementeren, dan zou ik een constraint kunnen opnemen dat de container elementen gesorteerd moeten zijn ( O(ln n) implementatie ), en een ander constraint dat de container elementen een gelijkheidsrelatie hebben ( O(N) implementatie). Dit gaat niet in .Net generics.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein