Is this standard in C++? In C#, I liked declaring nested namespaces like this:
namespace A.B
{
class X
{
};
}
The alternative was this, which is a little uglier:
namespace A
{
namespace B
{
class X
{
};
}
}
In C++, I wanted to see if it had a similar feature. I ended up finding this works:
namespace A::B
{
class Vector2D
{
}
}
Notice the ::.
I'm curious if this is standard C++ or if this is a MS feature. I can't find any documentation on it. My ancient C++98 reference book doesn't mention it, so I wonder if it's an extension from Microsoft or a new feature.
Yes, this is legal C++ 17 syntax. It is, however, not called embedded namespace, but nested namespace.
namespace ns_name::name (8) (since C++17)
[...]
8) nested namespace definition: namespace A::B::C { ... } is equivalent to namespace A { namespace B { namespace C { ... } } }.
Related
I have some C++ libraries that are written using nested namespaces. These libraries use many mathematical functions that, for readability, are better off read without explicitly specifying namespaces. Right now, a simplified version of the code would look like this.
namespace Base::Sibling1 {
float cos(float x) { return cosf(x); }
};
namespace Base::Sibling2 {
using namespace Sibling1;
float f(float x) { return cos(x); }
};
We wanted to move to use flatter namespaces mostly to make it easier to extend the library with sibling code. We had hoped that a simple change like this would work:
namespace Sibling1 {
float cos(float x) { return cosf(x); }
};
namespace Sibling2 {
using namespace Sibling1;
float f(float x) { return cos(x); }
};
Instead this fails now since Sibling2::f() calls cos(x) that is now ambiguous.
I have two questions
why is it ambiguous now and not int the first version?
is it possible to obtain the behavior we had before without listing all functions explicitly using using Sibling1::cos?
The ambiguity is due to how using directives work.
[namespace.udir] (emphasis mine)
2 A using-directive specifies that the names in the nominated
namespace can be used in the scope in which the using-directive
appears after the using-directive. During unqualified name lookup
([basic.lookup.unqual]), the names appear as if they were declared in
the nearest enclosing namespace which contains both the
using-directive and the nominated namespace. [ Note: In this context,
“contains” means “contains directly or indirectly”. — end note ]
3 A using-directive does not add any members to the declarative
region in which it appears. [ Example:
namespace A {
int i;
namespace B {
namespace C {
int i;
}
using namespace A::B::C;
void f1() {
i = 5; // OK, C::i visible in B and hides A::i
}
}
namespace D {
using namespace B;
using namespace C;
void f2() {
i = 5; // ambiguous, B::C::i or A::i?
}
}
void f3() {
i = 5; // uses A::i
}
}
void f4() {
i = 5; // error: neither i is visible
}
— end example ]
So given your structure of namespaces, according to bit I made bold in paragraph 2, when you write
using namespace Sibling1;
It kinda translates to this
namespace /* Enclosing */ {
using Sibling1::cos;
namespace Sibling2 {
float f(float x) { return cos(x); }
};
}
The namespace I marked as enclosing is either Base or the global namespace. The "kinda" bit (according to paragraph 3) is that it's not an actual declaration being added. I.e. if something named cos already exists in /* Enclosing */, it's not a re-declaration. This is by design, because using directives can potentially bring a lot of names in, and so it shouldn't cause an error when the names they bring are not actually used.
In your case however, the name brought in is used.
When /* Enclosing */ is Base, it matches only one declaration, the one in Sibling1, as-if it was declared in Base.
When /* Enclosing */ is the global namespace, it matches the actual declaration there too, presumably the one brought in by math.h (you seem to be using that). So you get an ambiguity (the name refers to two potential entities).
So on the whole, compilers that reject this code are behaving as expected. While I understand your plight, I don't think there's really a problem for you to solve here. If client code finds Base::Sibling1::cos too verbose, it itself can employ a using directive of the form using namespace Base;. Or using a namespace alias to shorten things namespace sib1 = Base::Sibling1;.
The problem cannot be reproduced as you describe it. Moreover, there is no reason that the flattening alone introduces ambiguities, if you use expose in the siblings the same names you introduced in Base. So, the root cause is probably in some parts of the code you are not showing.
The second version does not define cosf(), so you probably are using some namespace. If in that namespae there is also a cos() you create an ambiguity between the two overloads. I could reproduce this by using namespace std:
#include <iostream>
#include <cmath>
using namespace std;
namespace Sibling1 {
float cos(float x) { return cosf(x); }
}
namespace Sibling2 {
using namespace Sibling1;
float f(float x) { return cos(x); }
}
Online demo: the compilation error indicates which are the candidates behind the ambiguity. If you now comment the using namespace out, the ambiguity goes away, and the code compiles. Online proof.
Namespaces are meant to avoid naming conflicts and keep control of ambiguities:
Creating a namespace and systematically using namespace everywhere defeats the whole purpose.
On the other side, long using lists are painful to maintain, especially if you have to repeat them in several sibling namespaces. This is probably why the Base and the nesting were created in the first place.
In the first version, you do not show what's in Base. It is possible that some more tailored using clauses are used therein instead of full namespaces: if selectively injecting the really required functions in the Base namespace, they are made available within the siblings avoiding ambiguity that can be introduced by injecting the name of unnecessary functions.
In C++, if I have
namespace myNamespace {
boost::whatever();
}
will the compiler look for whatever() in the boost namespace or in myNamespace::boost?
The question is not about whether it will look for boost::whatever, but where it will find boost itself.
If you have a nested namespace definition with the name boost, it will hide the global boost namespace at its point of declaration. The global boost namespace will be visible up until the point where myNamespace::boost is declared (§3.3.2/2).
[ Note: a name from an outer scope remains visible up to the point of declaration of the name that hides it. [ Example:
const int i = 2;
{ int i[i]; }
declares a block-scope array of two integers. — end example ] — end note ]
So if you're calling boost::whatever() before the nested name myNamespace::boost is created, it will look for the global boost namespace. You can qualify the name with ::boost if you always want it to find boost in the global namespace.
First of all I think you mean this:
namespace myNamespace {
using boost::whatever; // NOT boost::whatever();
}
Remember that C++ namespaces are mainly to avoid naming clashes not a design mechanism, which means when you are using a method of other namespaces in another one, you just call the original one and there is no copy in new namespace scope. So, when you call myNamespace::whatever(), compiler would choose boost::whatever() not myNamespace::boost::whatever() because there is no boost namespace declared inside myNamespace.
For more details on namespaces you could see:
http://en.cppreference.com/w/cpp/language/namespace
Assuming you want to call a function using some qualification, you may end up using a local namespace rather than a global namespace:
#include <iostream>
namespace A { void f() { std::cout << "::A::f()\n"; } }
namespace B {
namespace A { void f() { std::cout << "::B::A::f()\n"; } }
void g() { A::f(); }
void h() { ::A::f(); }
}
int main() {
B::g();
B::h();
}
If you want to make sure you are picking up a specific namespace you'll need to use absolute qualification as in ::A::f().
I am trying to create a namespace in c++ in the following way:
namespace MyCompany.Library.Myproduct {
public ref class ClassWrapper
{
};
}
I am getting error:
Error 1 error C2059: syntax error : '.' ClassWrapper.h 7 1 MyCompany.Library.Myproduct
Why can not I have . in namespace?
Edit1
This namespace definition is in a c++/cli and would be used in c# code. in C# this namespace is valid, but it seems it is not valid in c++. How can define c# compatible namespaces in c++/cli code?
You're not allowed to use the dot in namespace name. However, you can have nested namespaces.
namespace Boap
{
namespace Lib
{
namespace Prod
{
class Llama
{
public:
Llama()
{
std::cout << "hi" << std::endl;
}
};
}
}
};
And instanciate your llama this way:
Boap::Lib::Prod::Llama l;
AFAIK namespace and classname follow the same namming rules than variables.
A variable's name cannot start with a numeric character, and the same apply to class / namespace's names. The same goes for ".".
EDIT: The following is pure assumptions, because I have no knowledge of C# or windows CLI.
Does it make sense that a nested namespace in C++ (eg Boap::Lib) would be translated into Boap.Lib in C#? Maybe it's just as simple as that.
Now, in 2023 it is possible to achieve what you want; with ::. You need to make sure the C++ Language Standard is set to at least C++17.
Then this code would compile and work:
namespace MyCompany::Library::Myproduct {
public class ClassWrapper
{
};
}
I'm learning C++ now. What are the complete legal entities that can be put in a namespace?
Legal entities here means valid members of a namespace
Oh, this is a real question. I'm coming from .net and I have the .net mindset.
Any code can be put inside namespace.
However main() function must be at global namespace. It cannot be put inside user-defined namespace.
namespace userns
{
int main()
{
return 0;
}
}
This program wouldn't compile link : http://www.ideone.com/k6SPc
Its because userns::main() will not be considered entry-point of the program; it became just like any other user function, not the standard main(). To compile it successfull, you've to add main() at global namespace:
namespace userns
{
int main()
{
return 0;
}
}
int main()
{
return 0;
}
This will compile link now : http://www.ideone.com/76Ynu
Anything can be put in a namespace (which is legal for C++, of course).
Actually, everything is in some namespace - the global namespace, if not specified.
Everything can be put in namespace except few "entities", which will not compile.
(1) Globally overloaded operator new and operator delete
namespace N
{
void* operator new (size_t size) // error
{ ... }
}
(2) Definition of the constructs which are declared in outer scope of the namespace; for example you have a class A declared globally then you cannot define its method inside your namespace N. In the same way, if you have method declared in a namespace N then you cannot put its definition inside namespace N::Nested (i.e. Nested is a namespace inside N).
//file
struct A {
void foo ();
static int i;
};
namespace N
{
int A::i = 0; // error
void A::foo() // error
{}
}
Demo: this is not allowed.
I remember at least these 2 restrictions from my experience. Don't know about specs.
Is it legal to replace something like this:
namespace foo {
namespace bar {
baz();
}
}
with something like this:
namespace foo::bar {
baz();
}
?
You can combine namespaces into one name and use the new name (i.e. Foobar).
namespace Foo { namespace Bar {
void some_func() {
printf("Hello World.");
}
}}
namespace Foobar = Foo::Bar;
int main()
{
Foobar::some_func();
}
Pre C++17:
No, it's not. Instead of a bunch of indented nested namespaces, it's certainly valid to put them on the same line:
namespace Foo { namespace Bar { namespace YetAnother {
// do something fancy
} } } // end Foo::Bar::YetAnother namespace
C++17 Update:
You can now nest namespaces more cleanly in C++17:
namespace Foo::Bar::YetAnother {
// do something even fancier!
}
For anyone wondering, the form namespace foo::bar is supported since C++17. References:
http://en.cppreference.com/w/cpp/language/namespace
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4230.html
Qualified names, like something::someting_else in C++ can only be used to refer to entities that have already been declared before. You cannot use such names to introduce something previously unknown. Even if the nested namespace was already declared before, extending that namespace is also considered as "introducing something new", so the qualified name is not allowed.
You can use such names for defining functions previously declared in the namespace
namespace foo {
namespace bar {
int baz();
}
}
// Define
int foo::bar::baz() {
/* ... */
}
but not declaring new namespaces of extending existing ones.
No; it's a syntax error.
Did you try it? Visual C++ gives me the following errors:
1>C:\...\foo.cpp(31): error C2061: syntax error : identifier 'bar'
1>C:\...\fooo.cpp(31): error C2143: syntax error : missing ';' before '{'
As per the grammar in $2.10, an identifier cannot have the token ":". So the name foo::bar is ill-formed.