question about anonymous namespace...

[Luna Moon]

I am reading the book "C++ Annotations", and here is a quote from the
book:

Namespaces can be defined without a name. Such a namespace is
anonymous and it restricts the
visibility of the defined entities to the source file in which the
anonymous namespace is defined.
Entities defined in the anonymous namespace are comparable to C’s
static functions and variables.
In C++ the static keyword can still be used, but its use is more
common in class definitions
(see chapter 6). In situations where static variables or functions are
necessary, the use of the
anonymous namespace is preferred.


--------------

Could anybody give me an example about why the anonymous name space is
the same as "static" variables and functions in C?

thanks!

 

[Ian Collins]

I am reading the book "C++ Annotations", and here is a quote from the
book:

Namespaces can be defined without a name. Such a namespace is
anonymous and it restricts the
visibility of the defined entities to the source file in which the
anonymous namespace is defined.
Entities defined in the anonymous namespace are comparable to C’s
static functions and variables.
In C++ the static keyword can still be used, but its use is more
common in class definitions
(see chapter 6). In situations where static variables or functions are
necessary, the use of the
anonymous namespace is preferred.

The quote says it all: "it restricts the visibility of the defined
entities to the source file in which the anonymous namespace is defined"

Which is exactly what "static" does in C.

 

[James Kanze]

Luna Moon <[email protected]> wrote:

[...]

Why? Because the standard says so. Actually, the effect is not
exactly the same.

// Before namespace
static int i;
static void f() { }
struct my_foo { };

// After namespace
namespace
{
int i;
void f() { }
struct foo { }; // no need for prefix on name, since it's now a local name
}

Another important difference is the linkage of the name. A
static variable or function has internal linkage. A name in an
anonymous namespace has external linkage---the reason it can't
be seen from other translation units is that it isn't namable in
them. (Formally, it is visible everywhere, but since it can't
be named, there's no way to actually see it.) A template can
only be instantiated over something that has external linkage,
e.g.:

template< int* p > class T {} ;

static int i ;
namespace {
int j ;
}

T< &i > ti ; // illegal...

BTW, the proper term is "unnamed namespace" (C++03 7.3.1.1).
The author of the C++ book you're reading should have taken
the time to get it right.

The term anonymous namespace seems pretty widespread to me.

 

[Guest]

... A template can only be instantiated over something that

has external linkage, e.g.:

template< int* p > class T {} ;

static int i ;
namespace {
int j ;
}

T< &i > ti ; // illegal...
T< &j > tj ; // legal.

To me, anonymous namespaces were just the C++ way of saying static.
The external linkage point is new to me. But:

Pointer-to-int as template argument? Instantiating templates over
something with external linkage? Could you provide a practical example
working with anonymous namespace but not working with static? Note
that you could also omit the static keyword to the same effect.

The term anonymous namespace seems pretty widespread to me.

I'd bet a horse and a carrot that "unnamed" is the literal meaning of
"anonymous".

Best regards,
Andreas.

 

[Michael Mol]

On Oct 23, 3:08 am, (e-mail address removed) (blargg) wrote:

[snip]

// Before namespace
static int i;
static void f() { }
struct my_foo { };

// After namespace
namespace
{
    int i;
    void f() { }
    struct foo { }; // no need for prefix on name, since it's now a local name

}

Now I'm curious. Take the following code from the same compilation
unit:

namespace
{
int i;
void x() { }
}

namespace
{
int j;
void y() { }
}

Would i be visible to y(), and j be visible to x()?

 

[Guest]

Now I'm curious. Take the following code from the same compilation

unit:

namespace
{
int i;
void x() { }
}

namespace
{
int j;
void y() { }
}

Would i be visible to y(), and j be visible to x()?

Generally, namespaces can be split across several compilation units.
The only exception to this rule are anonymous namespaces. If you would
split an anonymous namespace across several compilation units, it
wouldn't be the same namespace. That's because anonymous namespaces
are not truely anonymous, it's just that their name is not accessible
by the coder. The compiler, however, assigns a unique ID to them per
compilation unit.

But, as you're asking for the same compilation unit, yes, i is visible
to y(), and no, j is not visible to x().

Best regards,
Andreas.

 

[James Kanze]

To me, anonymous namespaces were just the C++ way of saying
static. The external linkage point is new to me. But:

Pointer-to-int as template argument?

Why not? It was the simplest example that came to my mind.

Instantiating templates over something with external linkage?

Anything you use to instantiate a template must have external
linkage. Those are the rules.

Could you provide a practical example working with anonymous
namespace but not working with static?

I just did. See above: declare the variable static, and you
can't use it to instantiate the template. Define it in an
anonymous namespace, and you can.

I run into this a lot because of const; const is static by
default, so something like:

template< int* p > class T{} ;

namespace {
int const i = 43 ;
}

T< &i > t ; // illegal.

You have to define the int:
extern int const i = 43 ;

(In practice, of course, most of the time, it's a user defined
class, and the template parameter is a reference, rather than a
pointer, and it's a function template, not a class template.
But the same principles apply.)

Note that you could also omit the static keyword to the same
effect.

Except that if I omitted the static keyword in my example, the
symbol would be visible in every module. And conflict with
another module which did exactly the same thing with the same
name.

I'd bet a horse and a carrot that "unnamed" is the literal
meaning of "anonymous".

Actually, no. From the way I understand English, anonymous
means that the name is hidden, and not visible; unnamed means
that it doesn't exist. In which case, anonymous is actually
closer to what really happens.

 

[Luna Moon]

On Oct 23, 3:08 am, (e-mail address removed) (blargg) wrote:

[snip]

// Before namespace
static int i;
static void f() { }
struct my_foo { };
// After namespace
namespace
{
    int i;
    void f() { }
    struct foo { }; // no need for prefix on name, since it's now a l ocal name

Now I'm curious.  Take the following code from the same compilation
unit:

namespace
{
    int i;
    void x() { }
}

namespace
{
    int j;
    void y() { }
}

Would i be visible to y(),
yes.

 and j be visible to x()?

no.

Same answer with a named namespace and without a namespace.

Why the above answers Pete? Thanks!

 

[Luna Moon]

The quote says it all: "it restricts the visibility of the defined
entities to the source file in which the anonymous namespace is defined"

Which is exactly what "static" does in C.

I thought "static" means "persistent", are the anonymous name space
persistent?

If you define "static" in a function, it will only get initialized
once and can be used forever...

 

[Ian Collins]

Last signature warning!

I thought "static" means "persistent", are the anonymous name space
persistent?

If you define "static" in a function, it will only get initialized
once and can be used forever...

Static in the context of C and linkage. It's unfortunate that both C
and C++ overload the meaning of static. Attempting to remove this
ambiguity is probably one of the reasons C++ introduced the unnamed
namespace.

 

[peter koch]

  According to my dictionary, "anonymous" derives from an old
  Latin word which derives from a Greek word, consisting of "an"
  ("without") and "onuma" ("name"), and meaning "nameless".
  I know, of course, that this leaves a lot of room for a debate
  about whether today this actually is "the literal meaning" of
  the word or not... However, my dictionary then produces "having
  an unknown or unacknowledged name" as the first of the three
  meanings it comes up with. (And now there's room for a debate
  whether my dictionary is actually worth anything...)

  Schobi

But your dictionary seems to agree with James Kanze, right? anonymous
= unknown name, unnamed = has no name. Regarding the etymology, it is
quite normal that the original meaning of a word changes meaning over
time.

/Peter

 

[James Kanze]

On Oct 22, 4:05 pm, Ian Collins <[email protected]> wrote:

I thought "static" means "persistent", are the anonymous name
space persistent?

In C++, the static keyword is very overloaded. It can affect
linkage or lifetime, or both, depending on where it is used.
When used with a local variable, it means static lifetime, which
corresponds more or less to the general English meaning (not to
be confused with persistent, which is usually used to mean that
the lifetime extends beyond the execution of the program). If
you apply it to a function or variable at namespace scope,
however, it means internal linkage---the opposite of extern
(more or less: extern can also mean that the declaration is not
a definition---the actual rules are not at all orthogonal).

All variables declared at namespace scope have static lifetime,
whether they are declared with the keyword static or not.
Member variables declared with the static keyword also have
static lifetime; without the static keyword, they have the
lifetime of the containing object. Variables defined with
local scope have static lifetime if defined with the static
keyword, automatic otherwise.

Functions don't have lifetime, in the sense C++ defines it;
they're just there.

If you define "static" in a function, it will only get
initialized once and can be used forever...

Not forever. Only until the end of the program. A persistent
variable could be used forever, but there is no direct support
for this in the language; you have to implement it yourself.

 

[James Kanze]

[...]
I'd bet a horse and a carrot that "unnamed" is the
literal meaning of "anonymous".
Actually, no. From the way I understand English,
anonymous means that the name is hidden, and not visible;
unnamed means that it doesn't exist. In which case,
anonymous is actually closer to what really happens.

According to my dictionary, "anonymous" derives from an
old Latin word which derives from a Greek word, consisting
of "an" ("without") and "onuma" ("name"), and meaning
"nameless". I know, of course, that this leaves a lot of
room for a debate about whether today this actually is
"the literal meaning" of the word or not... However, my
dictionary then produces "having an unknown or
unacknowledged name" as the first of the three meanings it
comes up with. (And now there's room for a debate whether
my dictionary is actually worth anything...)

But your dictionary seems to agree with James Kanze, right?
anonymous = unknown name, unnamed = has no name. Regarding the
etymology, it is quite normal that the original meaning of a
word changes meaning over time.

In everyday English, words can also be a bit ambiguous. I'm
pretty sure that a native English speaker would "feel" a
difference (at least a nuace of a difference) between anonymous
and unnamed, but there is also some overlap in the meanings. In
technical fields, we then specialize the meaning, so that it is
exact.

I did a quick find on the standard; all uses of anonymous were
for anonymous unions or anonymous bit fields, so Hendrik is
probably right that we should be talking about unnamed unions.
Regardless of the appropriateness of the term, based on its
natural English use, it's the formal term used in the standard.
Or "we should have been talking about unnamed namespace":
regardless of the standard terminology, "anonymous namespace"
has been adopted by the technical experts to describe this
feature, and is widely understood and used; in this specialized,
technical sense, anonymous and unnamed are exact synonyms, and
you can pretty much use them interchangeably without causing
problems of understanding.

 

[Guest]

...
regardless of the standard terminology, "anonymous namespace"
has been adopted by the technical experts to describe this
feature, and is widely understood and used; in this specialized,
technical sense, anonymous and unnamed are exact synonyms, and
you can pretty much use them interchangeably without causing
problems of understanding.

There you go. Geez, people! What a debate! My betting a horse was
supposed to end the nitpicking. It wasn't a real horse, see. There
wasn't the slightest ambiguity to begin with. Everyone knew exactly
what we were talking about.

Ok, who wants the carrot?

 

[Gennaro Prota]

James Kanze wrote:
[...]

In everyday English, words can also be a bit ambiguous. I'm
pretty sure that a native English speaker would "feel" a
difference (at least a nuace of a difference) between anonymous
and unnamed, but there is also some overlap in the meanings. In
technical fields, we then specialize the meaning, so that it is
exact.

FWIW, I feel the difference, too. However I can see "unnamed" as
deriving either from the substantive "name" or the verb "to
name", in which case it sound as "is not named". And my mind
leans towards the latter meaning when I add "nameless" to the
mix