Dear all, Thanks for your comments; I hope this responds to you all. I very much agree with David's words. For background, most developers in our project program purely as a means to an end; they are not software engineers and don't usually get a kick from discovering a cool new C++ or ABI feature. When they can focus on their problem at hand, and not on the language and the tools, we have done well. Programming languages, libraries or compilers prone to lead to mistakes reduce their efficiency. Our code base is some millions of lines of code, a complete built distribution is in the ballpark of 4 GB and 1000 shared libraries. We process large quantities of data, at present the code runs flat out on thousands of cores every day, soon on a much larger number of cores. So you may understand my ideas of performance consequences are rather concrete; I am aware others have different constraints. I'd posit template metaprogramming is a means to an end, another tool to get the compiler churn out code and help developers focus on problems interesting to them. It's definitely a tool I am pleased to have in my toolbox. However regardless of the languages and constructs used, I'll look at code maturity, maintainability, features and performance delivered per byte of object code, and factors such as build time or ability to debug the code. Like any tool, templates presently have some concrete strengths and weaknesses. I'll rejoice with you as compilers, linkers and run- times get more clever about templates. In the mean time we'll push for (substantial) economies by seeking a remedy to these present weaknesses. To us it is really not a question of whether there is bloat or not; it seems we can produce objective hard data with relative ease. What interests me most in the template bloat is that the awkward practical consequences are a result of fairly innocuous use of the language and the libraries, mostly in style taught in the best C++ text books and programming courses available. It is not even badly designed templates, and I would not be comfortable blaming just the tools either. Our tool chain actually does a decent job for a single shared library, about as good as any other as far as I know. I don't really know of production-quality whole program optimisers capable of processing hundreds of megabytes of machine code originating from several programming languages, or tools that give us a whole new class of liberty for physical packaging, or quality tools capable of combining C++ language level analysis and run-time feedback data. Pointers would be welcome. With the technology at hand today, it is difficult _not_ to make a lot of mistakes: bloat your code by 10+%, pass a 100'000-element map- of-vectors-of-vectors by value, accidentally instantiate the same template into hundreds of shared libraries, have a working set of 50 shared libraries for a particular "unit of work", or have orders of magnitude too many relocation entries in a shared library. Even the top programming and platform experts will sweat blood and tears to identify and analyse the issues, let alone devise practical remedies. There seems to be room for some novel thinking and tooling in this area. Of course not every project deals with such issues. Like you, we do the best we can to improve the classes and the tools, but we really need to look at the reality in the eye as we do that. Some of us spearhead the technology for tomorrow, but it takes wisdom to know what is the right technology for the hordes behind, for the numerous different project circumstances. Best regards, Lassi PS. Please understand I am not picking on templates for the fun of it. I am an engineer, a practitioner. I am as aware of the benefits of well-designed advanced templates as I am of the weaknesses. We recently introduced expression templates into a key algorithm. The change had been resisted for years; careful analysis of the performance costs of the "old-fashioned" code finally overcame the main technical and political arguments and we begun the migration. We are pretty unanimously pleased with the result. The costs associated with the templates may in due course produce similar migration advice. It could be investment into custom tooling, changes to our programming idioms, and other avenues.