static function in named namespace

[Yuanfang Chen]

Hi all,

I am confused by code like this

namespace foo {

static void bar() {...}

}

what's the purpose of static here?

best,
yuanfang

[Jorgen Grahn]

On Tue, 2013-10-22, Yuanfang Chen wrote:
> Hi all,
>
> I am confused by code like this
>
> namespace foo {
>
> static void bar() {...}
>
> }
>
> what's the purpose of static here?

The same as in the global namespace. What do you think its purpose
is there?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Chris Vine]

On Tue, 22 Oct 2013 12:49:36 -0700 (PDT)
Yuanfang Chen <tabloid...@gmail.com> wrote:
> Hi all,
>
> I am confused by code like this
>
> namespace foo {
>
> static void bar() {...}
>
> }
>
> what's the purpose of static here?

Presumably to give foo::bar() internal linkage.

In C++11 (but not C++98/03) the same can be achieved by putting the foo
namespace in unnamed namespace, provided there is nothing in foo
namespace that is intended to have external linkage.

However, this construct is pretty unusual. If bar() has internal
linkage, there is usually little point in not having it also in global
namespace.

Chris

[Tobias Müller]

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> However, this construct is pretty unusual. If bar() has internal
> linkage, there is usually little point in not having it also in global
> namespace.

I think it is actually quite usual. Static functions are usually helper
functions that are not generic enough to be reused. As such they are often
defined just before they are used, which is often inside a namespace.

Tobi

[Jorgen Grahn]

Different styles I suppose ... I tend to have

-- header --
namespace Foo {
void foo();
void bar();
}

-- source file --
#include "my_header.h"
using Foo:foo;
using Foo:bar;

namespace {
// general helpers
// helpers for foo, if needed
}

void foo()
{
...
}

namespace {
// more helpers for bar, if needed
}

void bar()
{
...
}


So my named namespaces live in the header files, and the source files
mostly use the global namespace and unnamed ones. I don't have any
major problems with your way, but I don't want most of my code to be
indented.

[Tobias Müller]

Jorgen Grahn <grahn...@snipabacken.se> wrote:

[...]

> I don't have any
> major problems with your way, but I don't want most of my code to be
> indented.

I don't indent namespaces anyway. Usually I don't have more than one
namespace in a file so I don't see any advantage in it.

Tobi

[Chris Vine]

Interesting: each to their own. I usually put that stuff in unnamed
namespace and have done with it, or if the functions are small enough
code them as lambda expressions.

The only occasion where I tended to use the static keyword to acquire
internal linkage for functions only used in one translation unit was
with functions (say callbacks) with C linkage specification. Because
the 'extern C' declaration suppresses namespace name mangling, and in
C++98/03 functions in unnamed namespace had external linkage, this was
an open invitation to ODR violation. This was resolved in C++11 by
requiring unnamed namespace to have internal linkage so it is now safe
with functions with C linkage specification.

Chris

[Richard Damon]

I believe it will allow two separate translation units to define bar()
independently without conflict, just like in the global namespace.

[Jorgen Grahn]

On Wed, 2013-10-23, Tobias Müller wrote:

Yeah, that was something I considered doing for a while. In the end
it boiled down to "I don't want others to have to fight their editor
about the indentation" and "I don't want to learn how to train Emacs
not to indent namespaces".

(On the other hand I'm not consistent: Emacs wants to indent 'extern
"C"' blocks and that's clearly crazy from a C perspective.)

[Tobias Müller]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Wed, 2013-10-23, Tobias Müller wrote:
>> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>>
>> [...]
>>
>>> I don't have any
>>> major problems with your way, but I don't want most of my code to be
>>> indented.
>>
>> I don't indent namespaces anyway. Usually I don't have more than one
>> namespace in a file so I don't see any advantage in it.
>
> Yeah, that was something I considered doing for a while. In the end
> it boiled down to "I don't want others to have to fight their editor
> about the indentation" and "I don't want to learn how to train Emacs
> not to indent namespaces".

In my experience this is only a problem when inserting something at the
very beginning of the namespace. At least Visual Studio only considers the
local context when indenting.
Except when you autoformat the whole file of course, but I almost never do
that.

> (On the other hand I'm not consistent: Emacs wants to indent 'extern
> "C"' blocks and that's clearly crazy from a C perspective.)

You mean because of the usual #ifdef __cplusplus guards?
Conditional compilation like that makes "correct" indenting impossible
anyway.

Tobi

[Jorgen Grahn]

I meant it's "clearly crazy" because you want to distract C users of
your header file as little as possible, so they don't petition you to
drop C++ compatibility ...

At least with Emacs, I don't think the indenting logic looks at
#ifdefs at all.

[Rupert Swarbrick]

Jorgen Grahn <grahn...@snipabacken.se> writes:
> At least with Emacs, I don't think the indenting logic looks at
> #ifdefs at all.

The curly bracket in

extern "C" {

makes Emacs indent the following line. But if you manually put the first
declaration at column zero, Emacs "does what you want" for following
ones.


Rupert

[Rupert Swarbrick]

Jorgen Grahn <grahn...@snipabacken.se> writes:
> At least with Emacs, I don't think the indenting logic looks at
> #ifdefs at all.

[Yuanfang Chen]

Same here.

I'm confused at first because unnamed/global space is the most common place I've seen to put stuff with internal linkage. I only put reuse code inside a named space. Now I figured it is a way to put some implementation inside header file.