On 19 May 2010 18:54, David Abrahams <dave@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.”
In that conversation you say that: "As far as I know, getting everything just right involves walking the line between static and dynamic polymorphism, compiling some generic things down to object code, and leaving others to be "instantiated" inline." I think nobody can object to that, and the discussion/problem is about where to draw the line. But I could have misunderstood =) What I find strange is that Boost librariy developers, in general, seems to agree that template bloat is of no or little concern, #include dependencies is of no or little concern, and compilation time for end-user is of absolutely no concern. A few developers bothers with this, and their work I appreciate very much. The one -big- concern is that every piece of code is visible so that it can be inlined in every compilation unit. For performance. Why so? Performance is a very complicated matter as everybody knows, and inlining is no holy grail. Performance is improved by analysis of a running program and taking proper action, but the more time I sit around waiting for compilation to finish after minor modification the less time I can spend on such activities. It would, I think, be beneficial to Boost if the standpoint on header only was less strict, and that ideas about hiding implementation details in .cpp files were not looked upon as craziness. =) Looking forward to a wrapped up Boost btw, if Booster ever comes to life! Cheers, Christian