Anonymous namespace vs static

[gauravbjain]

I am planning to move from ‘static’ keyword to anonymous namespace for
variables/functions which are local to a translation unit. This is to
move code closer to C++, since static for file level names is
deprecated by standard.
I am queries if doing this may have any downside associated with it,
since it would give external linkage to all these names? May be size
increase of generated object files which I believe should be taken
care by final symbol stripping. Suggestions?

--

[Victor Bazarov]

ga*********@gmail.com wrote:

I am planning to move from ‘static’ keyword to anonymous namespace for
variables/functions which are local to a translation unit. This is to
move code closer to C++, since static for file level names is
deprecated by standard.
I am queries if doing this may have any downside associated with it,
since it would give external linkage to all these names? May be size
increase of generated object files which I believe should be taken
care by final symbol stripping. Suggestions?

You're correct, the only potential downside is the increased number of
external names in every module that contains objects and functions in an
unnamed namespace. The linker is unlikely to run out of memory while
processing them, however, I don't think you'd notice anything. The size
of the object module should only affect the speed at which the linker
can output the resulting executable. As you suggest, most of the modern
linkers are smart enough to remove parts of the executable that are not
used (or exported, in a dynamic library). Just out of curiosity, how
big is your project?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[=?windows-1252?Q?Marcel_M=FCller?=]

Hi,

ga*********@gmail.com schrieb:

I am planning to move from ‘static’ keyword to anonymous namespace for
variables/functions which are local to a translation unit. This is to
move code closer to C++, since static for file level names is
deprecated by standard.

static linkage is deprecated?
Well, the second meaning of static has always been a bit confusing for
beginners. But the anonymous namspaces are none the better. The have
also an excemption: the implicit using statement.

I am queries if doing this may have any downside associated with it,
since it would give external linkage to all these names?

I don't think so. Since the namespace has no name, the functions cannot
be exposed by a biunique global symbol name anyway.

May be size
increase of generated object files
which I believe should be taken
care by final symbol stripping.
Suggestions?

Simply do it.
Marcel

[Rolf Magnus]

Marcel Müller wrote:

ga*********@gmail.com schrieb:

>I am planning to move from ‘static’ keyword to anonymous namespace for
variables/functions which are local to a translation unit. This is to
move code closer to C++, since static for file level names is
deprecated by standard.

static linkage is deprecated?

Yes.

Well, the second meaning of static has always been a bit confusing for
beginners.

So this one is the second? Who numbered them?

But the anonymous namspaces are none the better. The have
also an excemption: the implicit using statement.

Not sure what you mean by that.

>I am queries if doing this may have any downside associated with it,
since it would give external linkage to all these names?

I don't think so. Since the namespace has no name, the functions cannot
be exposed by a biunique global symbol name anyway.

The standard requires them to have external linkage. And the compiler I use
does actually provide them as external symbols using some unique prefix for
the symbol name. Why it needs to do this, I don't know.

[Victor Bazarov]

Rolf Magnus wrote:

[..]
The standard requires them to have external linkage. And the compiler I use
does actually provide them as external symbols using some unique prefix for
the symbol name. Why it needs to do this, I don't know.

The creators of linkers probably know. If I were asked to speculate,
I'd probably say that the linker can utilise "near" addressing for
symbols without external linkage and is forced to use "far" addressing
for symbols with external linkage. It might have to play into the
instructions the compiler creates for loading those addresses and
passing them as arguments when calling external functions...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Oct 1, 7:05 pm, Rolf Magnus <[e-mail]:

[re definitions in anonymous namespaces...]

The standard requires them to have external linkage. And the
compiler I use does actually provide them as external symbols
using some unique prefix for the symbol name. Why it needs to
do this, I don't know.

Possibly for its implementation of export:-). (Seriously,
probably just because that's the simplest solution. Generate
the unique name, and for the rest, treat it just like anything
else. No special cases, no extra code, etc.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]