4 ms·

Can you explain WHY an easy to follow, well-structured program that does not abuse language features is a bad thing? Even if it uses the functional language kno

Can you explain WHY an easy to follow, well-structured program that does not abuse language features is a bad thing? Even if it uses the functional language known as C++ templates to calculate a large amount of things at compile time? Heck, in this case, you could think of the compiler as a slow, purely functional, interpreter :) EDIT: Note that I am not endorsing C++ or doing crazy things with templates. I tend to like C++ personally, but have also been finding the simplicity of C to be quite nice, and have worked with a decent number of other languages (popular and academic, with varying degrees of time spent from professional to a small side project). I'm merely curious about why using the template system to calculate things (even if they're large, complicated things) is immediately declared as "bad" if the code is well-written, rather than something that requires 6 months of study to really understand.

virtue3 12y ago
The only super legit argument I've heard in favor of _not_ using templates or avoiding them in general is because of the code generation bloat - which is an issue on the consoles I worked on (every K counted on our wii app - we really did run down to the meg in memory usages). That and not all compilers at the time (even as recent as 2007 when I was working on wii) would compile templates well. Now it's much more mature and more widely supported (at least on x86).
- sjolsen 12y ago
  > The only super legit argument I've heard in favor of _not_ using templates or avoiding them in general is because of the code generation bloat And even then, it's important to recognize that bloat is a relative measure. If you use just one instantiation of a template, you're not paying for multiple versions of the code. If, on the other hand, you use multiple instantiations, the code will be bloated compared to, say, a single type-erased version— but will not be any bigger than if you had written several "instantiations" of the same code by hand. There's a tradeoff to be made, too, since a statically-typed version of a function will probably be faster than a type-erased version. Anyway, w.r.t. bloat, templates aren't the problem; static polymorphism is (can be). Templates are just a way of implementing static polymorphism.
  - kazinator 12y ago
    Indeed, if you use one expansion of a template, then the bloat is just that of whatever code the template generates, which would still be there if you wrote the same inline code by hand. If that code is inline code, you get the same inline bloat.
- kazinator 12y ago
  C++ compilers handled templates very well for me in the late 1990's. I wrote template headers in such a way that they could be included into a common .cc file, where template instantiations could be placed. By defining some #define symbol prior to including a template header, I would force it to supply the definitions. Without the #define, no other translation unit had access to the template bodies, and so generating bloat couldn't happen. (Another way is to have two headers: foo.h for the template declaration and foo-impl.h for the bodies of the template functions: foo-impl.h is only included in the translation unit that instantiates.) If the templates for different types are instantiated in the same translation unit, that maximizes the opportunity that the code for identical expansions can be merged (if the compiler supports it). But more importantly, you control the bloat through the discipline of having a catalog of explicit expansions. I avoided code bloat not only by using the above trick, but simply by writing light-weight templates. Templates cause particular bloat when they are inlined, because inline functions cause bloat, and inline templates generate them. The solution: don't put anything into the body of a template function that you wouldn't put into an inline function. Secondly, make the tiny inline template function rely only on non-template pieces to do its job. Sometimes designing this way creates a type-fragile implementation. However, if that code is used properly through the templates (and only through the templates), then it is safe. Perhaps C++ compilers handle templates better now in the sense of managing the expansion more transparently and merging some of the bloat; but manual techniques have worked well for a long time.

virtue3 12y ago

The only super legit argument I've heard in favor of _not_ using templates or avoiding them in general is because of the code generation bloat - which is an issue on the consoles I worked on (every K counted on our wii app - we really did run down to the meg in memory usages). That and not all compilers at the time (even as recent as 2007 when I was working on wii) would compile templates well. Now it's much more mature and more widely supported (at least on x86).

sjolsen 12y ago
> The only super legit argument I've heard in favor of _not_ using templates or avoiding them in general is because of the code generation bloat And even then, it's important to recognize that bloat is a relative measure. If you use just one instantiation of a template, you're not paying for multiple versions of the code. If, on the other hand, you use multiple instantiations, the code will be bloated compared to, say, a single type-erased version— but will not be any bigger than if you had written several "instantiations" of the same code by hand. There's a tradeoff to be made, too, since a statically-typed version of a function will probably be faster than a type-erased version. Anyway, w.r.t. bloat, templates aren't the problem; static polymorphism is (can be). Templates are just a way of implementing static polymorphism.
- kazinator 12y ago
  Indeed, if you use one expansion of a template, then the bloat is just that of whatever code the template generates, which would still be there if you wrote the same inline code by hand. If that code is inline code, you get the same inline bloat.
kazinator 12y ago
C++ compilers handled templates very well for me in the late 1990's. I wrote template headers in such a way that they could be included into a common .cc file, where template instantiations could be placed. By defining some #define symbol prior to including a template header, I would force it to supply the definitions. Without the #define, no other translation unit had access to the template bodies, and so generating bloat couldn't happen. (Another way is to have two headers: foo.h for the template declaration and foo-impl.h for the bodies of the template functions: foo-impl.h is only included in the translation unit that instantiates.) If the templates for different types are instantiated in the same translation unit, that maximizes the opportunity that the code for identical expansions can be merged (if the compiler supports it). But more importantly, you control the bloat through the discipline of having a catalog of explicit expansions. I avoided code bloat not only by using the above trick, but simply by writing light-weight templates. Templates cause particular bloat when they are inlined, because inline functions cause bloat, and inline templates generate them. The solution: don't put anything into the body of a template function that you wouldn't put into an inline function. Secondly, make the tiny inline template function rely only on non-template pieces to do its job. Sometimes designing this way creates a type-fragile implementation. However, if that code is used properly through the templates (and only through the templates), then it is safe. Perhaps C++ compilers handle templates better now in the sense of managing the expansion more transparently and merging some of the bloat; but manual techniques have worked well for a long time.