What is static function?

[Aneel]

What do we mean when using static function:
i.e. what difference is produced for

static int func(int a) {return a;}
AND
int func(int a) {return a;}

 

[Ali Karaali]

What do we mean when using static function:
i.e. what difference is produced for

static int func(int a) {return a;}
AND
int func(int a) {return a;}

The function has internal linkage untill now.
You can do that also using a nameless namespace

namespace {
int func(int a)
{
return a;
}
};

Ali

 

[James Kanze]

The function has internal linkage until now.

It depends on the context. If the function is a member
function, then it still has external linkage. Static is a bit
overused in C++, and has different meanings according to
context.

You can do that also using a nameless namespace

No. A function in an unnamed namespace still has external
linkage.

 

[Ali Karaali]

No.  A function in an unnamed namespace still has external
linkage.

n1804 says: 7.3.1.1:
"The use of the static keyword is deprecated when declaring objects
in a namespace scope (see annex D); the unnamednamespace
provides a superior alternative."

I understand from here, names in an unnamed namespace has internal
linkage.
Can you explain me what your point is?

Ali

 

[James Kanze]

n1804 says: 7.3.1.1:
"The use of the static keyword is deprecated when declaring
objects in a namespace scope (see annex D); the
unnamednamespace provides a superior alternative."

I understand from here, names in an unnamed namespace has
internal linkage.

That's not what it says. It says that the unnamed namespace
provides a *superior* alternative, not that it does the same
thing.

Can you explain me what your point is?

A function (or an object) in an unnamed namespace still has
external linkage. It's an important point, and it's the reason
why using an unnamed namespace is superior to using static.
There are some uses (e.g. template arguments) which require
external linkage.

 

[Ali Karaali]

That's not what it says.  It says that the unnamed namespace
provides a *superior* alternative, not that it does the same
thing.


A function (or an object) in an unnamed namespace still has
external linkage.  It's an important point, and it's the reason
why using an unnamed namespace is superior to using static.
There are some uses (e.g. template arguments) which require
external linkage.

Bruce Eckel says in "Thinking in C++":
"If you put local names in an unnamed namespace, you don’t need
to give them internal linkage by making them static.
C++ deprecates the use of file statics in favor of
the unnamed namespace."

And you say they have still external linkage. However, we can't
use(reach)
them in an another module? Would you mind if I asked to expain what
Mr. Ecker wanted to say?
(using some code)


Ali

 

[James Kanze]

Bruce Eckel says in "Thinking in C++":
"If you put local names in an unnamed namespace, you don’t
need to give them internal linkage by making them static. C++
deprecates the use of file statics in favor of the unnamed
namespace."

And you say they have still external linkage. However, we
can't use(reach) them in an another module?

Unless you're compiler supports export. (Even then, it's not
clear what "another module" means---but you can instantiate a
template over a symbol defined in an unnamed namespace, even if
the implementation code of the template was exported, and thus
in "another module".)

Seriously, an unnamed namespace works exactly like any other
namespace: a defined symbol (regardless of what) follows no
special rules just because the namespace is unnamed. In theory,
at least, the symbol is fully visible in all translation units.
Except that you can't name the namespace which contains it, so
you have no way of getting at it. (In practice, compilers don't
make any distinction whatsoever, and giving an internally
generated name to an unnamed namespace. Taking pains to ensure
that it's not one you might use, and that it won't be the same
in different translation units.)

Would you mind if I asked to expain what Mr. Ecker wanted to
say?

He probably wanted to say exactly what he said: if you put names
in an unnamed namespace, you don't need to give them internal
linkage, because the fully qualified name can't be referred to
from a different translation unit. (At least by a coder---as I
said, it can be seen when instantiating an exported template on
it, and depending on how export is implemented, or your point of
view, that can be considered a different translation unit.)

Part of the motivation behind introducing unnamed namespace is
related to templates. (Another part is that you have no means
of giving things like class names internal linkage, so some
other technique had to be introduced to make them invisible in
other translation units.)