Use of CeePlusPlus templates to execute code at CompileTime. SmugLispWeenie''''''s will no doubt view this as an inefficient reinvention of LispMacro''''''s. ''They are correct of course, templates aren't nearly as powerful as macros, and I'm not a LispWeenie.'' * Before this leads to later confused responses: they are both TuringEquivalent, but Lisp macros are exactly as expressive as regular Lisp functions, whereas C++ templates are much less expressive than the rest of C++; they must be used in strange and kludgy ways in order to achieve general computations beyond what they were nominally designed for. This is partly because C++ is not a HomoiconicLanguage. * See also CeePlusPlusTemplatesCommonLispMacrosComparison. * As another non-LispWeenie, I have to say that Templates were a very nice try by some hard working people, but the fact that people have fallen into the TuringTarpit with them has proven that they were insufficient. Anything less than a fully expressive macro language will inevitably have shortcomings. Fundamentally, the problem is that there are so many problems that can be solved in OOP metaprogramming by, on being given type T1, ** Define type T2 ** Iterate across the members of T1, create wrappers of them and add them to type T2 ** all at compile time. Consider how much can happen once you can iterate across the members/methods. Implementing garbage-collected classes becomes possible. Forwarding access to methods becomes simple. C++ is a very nice language, why can't I just code my macros and templates in it? If so, classes could simply be objects at compile time - a class would contain an array of method-describing structs, an array of member-describing-structs, etc. You could iterate across this and use the information for the glorified mess of string parsing that is the actual process of creating the templated class. If the "class" object included some way to be converted into an aggregate, then implementing reflection becomes simply taking each given class and adding a static "type" member and a dynamic "getType" operation. Why should Lisp be the only language where macros and code are written in the same (or similar) dialects? Even if it was just a modified version (like allowing easier emission of code and forcing class-defining operations to be functional) of C++ for macros, it would be better than anything else. You can do all of this in C#, but it's at run-time so you lose the speed advantage and the static type-checking, making calling operations on your generated classes a massive pain. Simply put: if your language isn't good enough to define your own programs in, why is it good enough for the logic itself? --MartinZarate See http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html KrzysztofCzarnecki and UlrichEisenecker's GenerativeProgrammingBook is a wonderful tour of the world of generative programming. Much of it is devoted to demonstrating the power of the CeePlusPlus template mechanism. They observe that it is a TuringComplete language that allows a C++ program to manipulate itself at compile time. They go on to show how to build the elements of structured programming (if, switch, while, for) and a lisp processor (cons, car, cdr, ...). The C++ StandardTemplateLibrary makes only very primitive use of the template mechanism. Programmers must specify their desires by explicitly choosing an implementation, rather than by describing their intent. Czarnecki and Eisenecker show how you can use templates to implement a DomainSpecificLanguage for a client's use: the template meta-program then constructs the appropriate implementation classes based on the preferences. Another area they explore is optimization. They have been involved in the development of the MatrixTemplateLibrary (MTL). Using templates to define LazyEvaluation at compile time, they show how a matrix expression such as (a+b)*(c+d) can be optimized at compile-time by a suitable Template Metaprogram: the expression is compiled into expression objects which are optimized (re-structured) by the templates. The restructured expression objects are evaluated when the result is assigned. (See ExpressionTemplate.) There's much more to the book than C++ templates: they discuss a range of methods and languages for generative software (I found the first couple of chapters a bit tedious). They make a strong case for the limitations of today's component technologies. They give a thorough review of Microsoft's IntentionalProgramming research http://www.research.microsoft.com/IP). But their practical examples are written in C++. I had thought I understood templates: now I know how much I had missed. --DaveWhipp. ---- BlitzPlusPlus uses a lot of template metaprograms. The PatternTemplateLibrary also has some interesting, though convoluted, use of parameterization. ---- DaixtroseLib is a CeePlusPlus header library that retakes ideas developed by ToddVeldhuizen and GeoffreyFurnish. DaixtroseLib is ExpressionTemplate''''''s for everyone. With the help of this library the ExpressionTemplate technique now is available for everyone. DaixtroseLib takes the task of delaying the evaluation and building the expressions, such that users only have to provide the appropriate evaluation methods and by this can plug any existing class into the ExpressionTemplate context. The library offers fine-grained control over disambiguation rules and copy/reference semantics and was designed to have other libraries built on top of it. --MarkusWerle ---- See http://arxiv.org/html/cs.CL/0104010 ---- Other books: ''CppTemplatesTheCompleteGuide'' by DavidVandevoorde and NicolaiJosuttis, ModernCeePlusPlusDesign, CppTemplateMetaprogramming, which describes BoostMpl (MPL). ---- CategoryCpp CategoryCppTemplates CategoryMetaprogramming CategoryLanguageFeature TemplateMetaprogrammingTechniques