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

[Dirk Mueller]

On Saturday 06 March 2004 20:50, Dr. Juergen Pfennig wrote:

> Object orientation sometimes causes lots of classes, many of them only
> being used internally in a module.

do you have a proof for the "many classes are only used internally". Because 
in my experience, many classes are actually public API. Worst case is Qt, 
where 95% of all exported symbols are public API. 

We have the KDE_NO_EXPORT macro, which is reducing the number of exported 
symbols as well as giving the compiler a hint to use faster calls (methods 
and variables which are library-local can be called with less overhead and 
are therefore faster). 

The other recommended way is to use a linker version script. There are plenty 
of libraries that could make use of it, the most prominent example is 
libkdeprint, since 98% of its symbols are private API, which is not properly 
namespaced and often causes conflicts with symbols with the same name in 
userspace code. a linker version script avoids unnecessary symbols (reduces 
symbol conflicts and helps relocation speed), but it does not reduce the 
calling overhead, since the compiler doesn't know that a symbol isn't going 
to be exported. 

For examples on how to use a version script, see libkhtml. 

> I could use KDE_NO_EXPORT to hide class members and to reduce the .so
> module size. But is this OK? I found that KDE_NO_EXPORT is rarely used.

Thats because nobody cares about it. People are more busy adding new features 
than to make the existing features run fast with minimum memory footprint. 

> Could someone please add a KDE_NO_INLINE macro to kdemacros.h? Sometimes
> you know that inlining a function gives no real speed improvement but
> increases code size.

No, you don't know that. give the compiler a choice in what to inline. for 
example, constant folding can make a method inline. 

simple example: 

bool somefoo(bool b) const 
{
  if(b == true) {
  // 50kb of sourcecode here
  }
  else return true;
}

the compiler can nicely constant-fold somefoo when it can be sure that the 
passed argument evaluates to "false". 

As a rule of thumb: always give the compiler the chance to optimize code. if 
you purposefully not inline code or set flags to avoid inlining, you're 
preventing that a better compiler can produce better code. Don't do that. 


Dirk