(1) how to hide helper classes (2) KDE_NO_INLINE missing?

Simon Hausmann hausmann at kde.org
Sun Mar 7 14:40:29 GMT 2004

On Sunday 07 March 2004 10:40, Dr. Juergen Pfennig wrote:
> On Sunday 07 March 2004 09:38, Simon Hausmann wrote:
> > This probably sounds stupid, but: Why not simply make the function not
> > inline instead?
> In that part of the world were 95% of all programmers work the compiler can
> be very aggressive with inlining. It grabs almost everything (think about
> dtors of long-lived classes or error handling code) and makes the program
> larger if you don't give it some hints.

Then I'm certainly part of the 5%, because my experience with at least gcc is 
that it is not overly aggressive at inlining, provided I don't compile with 
-gen2 -O12 -fmachs-mir-flott ;-)

(note that I'm not saying that it's not inlining enough for my taste)

> Also for that compiler there is little need to place something in a .cpp
> file - you better put things in header files there. The .cpp files are
> there mostly for "historic" reasons.

I disagree. The majority of methods in a class I write in say a library I do 
not want to have possibly inlined, because for example

1) I want to be able to change the implementation and see the applications 
picking up the change without having to recompile them

2) I know it can't be inlined, because for example it is a virtual method

So instead of a blacklist ('hey, don't inline this, and this, and this, ah and 
this method, too') in the header file I want to use a whitelist ('please, if 
possible inline this method, it's only a two-liner and quite simple') . 
That's less work for the programmer and IMHO it's the common case.

Besides of course that not having everything in the header file means the 
compiler has to spend less time with parsing, so the overall build time 
decreases and my productivity increases.

> Their linker is quite smart (and must be, see .cpp files above) - it
> optimizes away whatever is not used or exported (from a DLL).

At the cost of build time.


More information about the kde-core-devel mailing list