From kde-core-devel  Mon Feb 16 15:24:30 2004
From: Dirk Mueller <mueller () kde ! org>
Date: Mon, 16 Feb 2004 15:24:30 +0000
To: kde-core-devel
Subject: Re: Static functions
Message-Id: <200402161624.30587.mueller () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=107694507710276

On Monday 16 February 2004 16:08, Thiago Macieira wrote:

> Oh, that won't work because static functions have to be defined in the
> same file. You know that as well as I do and this wasn't the original
> discussion.

Well, I'm not sure where you see the original discussion, but the point I 
started replying to was this one from Ian Geiser:

<quote>

there is a 
tendency to put these in a utility class.  we have found its just as easy 
(and remarkably clean) to put them in a namespace, and leave them as static.

</quote>

I was pointing out (slightly unprecise, I agree), that there is an important 
difference between static in class and static in namespace. The latter is 
just like a static outside a class and outside a namespace, as such, it 
requires to be defined in *each* compilation unit, and therefore gets 
*duplicated* for *each* compilation unit. 

if you include your utility headerfile with all those static-namespaced 
methods in your 1000 source files you build your application from, you get a 
lot of compiler warnings and a lot of duplicated object code which is a 
remarkably clean way to explode the binary size of your library|application.

So, what you want is a macro that marks a (namespaced) function as local to 
the target, but not to the compilation unit. There is such a thing already, 
its called KDE_NOEXPORT. 

It does exactly combine the advantage of using "static" on functions for 
libraries, without all the downsides anonymous namespaces and static 
namespaced functions give you. Yes, I know that all theoretic C++ books 
advertise these like sliced bread. Reality is different. 

> I was assuming that if anyone wanted to not to export a symbol, that
> he'd also know that the symbol has to be defined in the same file.

No, it doesn't *have* to be defined in the same file. Only if you use weird 
constructs (anonymous namespaces, static in namespaces). Better don't do 
that. 


Dirk