Static functions
Dirk Mueller
mueller at kde.org
Mon Feb 16 15:24:30 GMT 2004
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
More information about the kde-core-devel
mailing list