Re: [boost] [Booster] Or boost is useless for library developers

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: David Abrahams (dave_at_[hidden])
Date: 2010-05-20 12:52:41

At Thu, 20 May 2010 10:16:03 -0500,
Christian Holmquist wrote:
> 
> On 19 May 2010 18:54, David Abrahams <dave_at_[hidden]> 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.”
> >
> > http://www.cpptalk.net/image-vp103267.html#103267
> >
> >
> >
> 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 =)

Perhaps; perhaps not.  I just think “template code bloat” is overhyped as
a problem and generally poorly understood, so when people make
unqualified statements about it like Gennadiy's above, I like to wave
a dowsing rod at it.

> 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.

> #include dependencies
> is of no or little concern, and compilation time for end-user is of
> absolutely no concern. 

I don't know any Boost developers who believe those things.

> A few developers bothers with this, and their work I
> appreciate very much.

Some have been better at dealing with it than others.

> 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 distinguishing feature of C++ among languages in
which high-level programming is possible, so we naturally have lots of
users who care a lot about performance.  Once you trade away
performance for something else, you can't get it back.  

On the other hand, if you use too little dynamic polymorphism, you can
end up with huge executables that blow the instruction cache.  It's a
balancing act.

> 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.

I know :(.  Try Clang; it compiles boost now and is wicked fast. :)

> It would, I think, be beneficial to Boost if the standpoint on header only
> was less strict, 

There is no strict standpoint on it.  Different developers have
different positions on the issue.

> 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!

Booster? I musta missed that thread.

-- 
Dave Abrahams           Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com