David Abrahams <dave <at> boostpro.com> writes:
At Thu, 20 May 2010 10:16:03 -0500, Christian Holmquist wrote:
On 19 May 2010 18:54, David Abrahams <dave <at> boostpro.com> wrote:
At Wed, 19 May 2010 19:49:33 +0000 (UTC), Gennadiy Rozental wrote:
Templates do lead to the larger code size and larger compilation time. You can hardly argue with that.
I certainly can. It all depends how they are used. If you use other means of polymorphism (e.g. virtual functions) on a fine-grained level, the cost in code size of dispatching to trivial functions that could otherwise be inlined can easily overwhelm “template code bloat.”
I was not trying to proof a theorem, but general trend (and my experience as well) is that template based solution in comparison with *semantically* identical solution based on runtime polymorphism usually takes longer to compile and produce larger code. Fun fact: in company I work for, the fear of code bloat and longer compilation/link time (admittedly based on some bad experience) lead to almost every instance of vector and shared_ptr to be explicitly instantiated. Hoverer much I dislike it I can't tell 200 developers "it's ugly - let's add 10 min to your compilation/link time".
What I find strange is that Boost librariy developers, in general, seems to agree that template bloat is of no or little concern,
I don't. You can see that from the design of Boost.Python, which assiduously tries to get everything that can be static into the library binary.
I myself is very heavy Boost.Python user. And in this case in spite of the fact that my code is probably longest to compile, I believe that for the most part Boost.Python got this balance right. Not everyone in a team agree with me though. Gennadiy