Static functions

[David Leimbach]

Hello Bo,
On Jan 12, 2004, at 7:56 AM, Bo Thorsen wrote:

> Hi all,
>
> I just convinced myself it was time to remind everyone of this old
> feature: Static functions. I know lots of you already know about this
> feature, but I've seen too many places where it isn't used, so I 
> thought
> I'd give a heads up on it.
>
> The reason for using these is optimization - especially when it comes 
> to
> libraries. And since almost all of KDE is made up of libraries, this
> really is important.
>
> First application: Helper methods:
>
> There are too many places in KDE where we have helper functions like 
> this:
>
> bool doSomething(...) {
>    ...
> }
>
> If you search the object file or the library after compilation (for
> example with readelf -s thefile.o) you will see the symbol in the 
> symbol
> table of the file. And the places that use these file will have a
> reference to this symbol. This means when the runtime linker loads the
> library, it needs to spend time matching the call to doSomething with 
> the
> place of the code. If you instead do this:
>
> static bool doSomething(...) {
>    ...
> }
>
> the symbol is no longer in the object file, and all uses are linked at
> compile time, so you no longer spend time in the linker.
>
> Another good thing here is that you won't pollute the local namespace
> inside the library, but that point is moot in KDE, since --enable-final
> makes it impossible to have two identical methods anyway.
>

This is a generally good reminder.  I believe some platforms such as 
Mac OS X
will allow you to make a list of all symbols that will be exposed in 
the resulting
object file whether you bothered to call them static or not.  Static is 
clearly a more
portable way to do this however.

How you feel about achieving the same goal with anonymous namespaces?

This too creates the situation where you've written "utility functions" 
that can only
be used in this particular translation unit and it avoids using static 
all over the place
to do so.

> Another application of this: Private methods.
>
> In KMail:kmgroupware.* I had a static attribute called
> mKOrganizerIfaceStub. This was used by various internal methods to call
> KOrganizer, and there was a connectToKOrganizer method that set up the
> stub, and a DCOP slot that listened to the user shutting down 
> KOrganizer.
>
> That means I had this:
>
> class KMGroupware : public QObject {
> private slots:
>   void unregisteredFromDCOP( const QCString& );
>
> private:
>   void iCalRequest( const QString& receiver, const QString& iCal,
>                     const QString& choice );
>   void iCalCancel( const QString& iCal );
>   void iCalReply( const QString& iCal );
>
>   static bool connectToKOrganizer();
>
>   static KOrganizerIface_stub* mKOrganizerIfaceStub;
> };
>
> (all irrelevant parts not shown.) In kmgroupware.cpp I then had the
> implementation of all these class items. This is - arguably - a nice
> object oriented approach, since the helper functions are private 
> methods
> here. It's unfortunately also bad for the runtime linker, since all 
> these
> symbols must be relocated at runtime.
>
> The iCal* methods only used the stub, but they were still object 
> methods
> because of leftover code from kroupware_branch (all this is from a
> refactoring process I did today).
>
> I changed the interface to be this:
>
> class KMGroupware : public QObject {
> private slots:
>   void unregisteredFromDCOP( const QCString& );
> };
>
> and in the .cpp file I now have:
>
> static KOrganizerIface_stub* mKOrganizerIfaceStub;
> static bool connectToKOrganizer() {
>   ...
> }
>
> and so on.
>
> This means the code is basically unchanged, but the header file is less
> cluttered and the number of relocations goes down, giving a shorter 
> load
> time of the library/application/part.
>
> This is not in any way an advanced feature, and it doesn't make that 
> big a
> difference. It's just that there are absolutely no reasons *not* to use
> this.
>
> I hope this was interesting or helpful.

It's very interesting and exactly the sort of discussion I like to see 
on kde-optimize :) so
I have forwarded it there :)


>
> Bo.