anonymous namespace qualifier

It has recently been brought to my attention that it is possible to use a namespace as a "qualifier" in the signature of a definition as opposed to using a block. EG:

Code:

---

//Begin declarations here
namespace ns
{
    extern int i;
    void foo();
    void bar();
}

//Begin definitions here
int ns::i = 5;
void ns::foo(){...}
void ns::bar(){...}

---

I did not know this was possible before, and I like this a lot, because:

• It avoids a huge useless block/indent.
• More closely resembles how you'd use static class encapsulation.

What I'm wondering though is: Is it possible to do something similar for an anonymous namespace? A lot of my .cpp files have internal helper functions/objects "forward declared" in an anonymous namespace, and then implemented later. I've tried:

Code:

---

namespace
{
    void helper();
}

//Begin implementations here
void helper(){...} //This is actually a brand new declaration
void ::helper(){...} //This doesn't compile

---

Is there any way to say: "This is the implementation for something declared in anonymous namespace", without actually opening a namespace block?

1) You do not have to indent on a namespace block.
In fact it's more common to find it not happening.
THe only exception if you have nested namespaces, but then you pretyt much open a can of worms about the pros and cons of nested namespaces.
Now I'm not saying they're necessarily wrong, but if you have nested namespaces without a very good motivation, then you're "doing it wrong".


2) actually

Code:

---

void ::helper()
{
  // do something
}

---

is the proper way to declare a function explicitely in the unnamed namespace.

BUT

you cannot at the same time declare a function with the same name in global scope.

The reason why should be Obvious, because there's no fundamental difference between calling ::helper() meaning the global function or the unnamed namespace function.
In your sample, remove the void helper()... line and it should compile and link properly.

Quote:

---

Originally Posted by OReubens

1) You do not have to indent on a namespace block.
In fact it's more common to find it not happening.

---

Yeah, but it still creates a block you have to track where it opens and closes. Not a huge deal, I agree, but it feels a bit messy.

Quote:

---

Originally Posted by OReubens

2) actually

Code:

---

void ::helper()
{
  // do something
}

---

is the proper way to declare a function explicitely in the unnamed namespace.

---

Really? Because that doesn't compile for me...

Quote:

---

error: explicit qualification in declaration of 'void helper()'

---

Using GCC.

Quote:

---

Using GCC.

---

Are you compiling for c++03 or c++11?

Quote:

---

Originally Posted by 2kaud

Are you compiling for c++03 or c++11?

---

With my MinGW, both std=c++98 and std=C++11 produce the same output. Were namespace rules changed with C++11? I am not aware of any changes being made to them with this latest release. Are you thinking about anything in particular?

I'll double check with an actual GCC on linux.

Quote:

---

Originally Posted by OReubens

2) actually

Code:

---

void ::helper()
{
  // do something
}

---

is the proper way to declare a function explicitely in the unnamed namespace.

---

Like monarch_dodra, I get a compile error when compiling a program with similiar code on g++ 4.8.2, with and without --std=c++11. I am also not able to verify this in the text of C++11. Could you quote the relevant paragraph(s)?

If it is indeed standard syntax, then this looks like a design mistake on the part of the standard committee: in general, ::x means that x is from the global namespace, so having it suddenly belong to an unnamed namespace is confusing.

Actually...

it appears the Original c++11 standard is somewhat dubious as to the exact expected workings in this case, later made prohibited, but for C++14 it's again being taken in for change.
http://www.open-std.org/jtc1/sc22/wg...fects.html#482

It works on all three compilers I use on a daily basis (one of them being VC2010/2012, the other 2 are not really anything of a reference, I sort of assumed it was legal since it compiled on all 3. It's quite rare to see all 3 of these agree to the same 'defect' (even if dubious).


So recap
it's technically an error for c++11
if it works, your compiler is already agreeing with c++14

It looks like it will be allowed in C++14, but since ::f is a name from the global namespace, this still will not help for monarch_dodra's case of a name from an unnamed namespace.

I see. That's interesting.

Well, I think I have my answers in regards to the original issue. Thanks all.