namespace A {
void F() {}
namespace B {
void F(int) {}
}
}
using A::B::F;
namespace A {
void G() {
F(); // OK
F(1); // Error: too many arguments to function void A::F()
}
}
int main() { return 0; }
I have this piece of code.
I defined two functions with same names but different signatures.
Then I use a using-declaration using A::B::F.
In A::G() compiler tries to resolve A::F() before A::B::F().
Are there any orders if there are such conflicts?
The deepest nested scope is searched first, and scopes are then searched outward if the name is not found. So first it would find a block-scope declaration of F inside G, if any; then it would find a declaration at the namespace scope of A, if any; and if that too failed it would search the global scope. Since using A::B::F; appears at global scope, A::F is always found first. Perhaps you should move the using declaration inside A.
It's definitely about placement.
namespace A {
void G() {
F(); // OK, A::F
using B::F;
F(1); // OK, A::B::F
}
}
Related
I'm doing online programming tests like leetcode, which requires only one .cpp file, so I have to place everything into one .cpp file.
And I used to write main() function ahead of any other functions, but that way I have to forward declare every function I use, which is very annoying. So I think of something like the snippet below:
namespace function;//oop,there is no such forward declaration
int main()
{
using namespace function;//compiler could not find this actually;
f1();
...
}
namespace function
{
f1(){...};
f2(){...};
...
}
But the compiler complains, since there is no forward declaration of namespaces (unlike functions), which makes the namespace invisible to the compiler.
Is there any way to forward declare a namespace? Just like
void f1();
int main()
{
f1();//ok,because there is a forward declaration
}
void f1()
{ ...}
The nearest thing to forward-declaring a namespace is to rely on the fact that they can be split up (unlike a class declaration), even into different translation units! Hence you can write
namespace funcion // [sic]
{
}
before main. Note well the braces.
If not having to forward declare functions is the most important goal, you can abuse the fact that a class also defines a namespace scope where you don't have to forward declare member functions.
Something like this:
struct program
{
int main()
{
f1();
f2();
return 0;
}
void f1(){}
void f2(){}
};
// The real main still needed here
int main()
{ return program{}.main(); }
Technically this works, but still not really recommended.
This won't solve your problem.
You can declare the namespace earlier like this:
namespace function {};
int main()
{
using namespace function;
f1();
}
namespace function
{
void f1() {}
}
but f1 is still not declared in main.
How about extracting the function declarations to a header file and including it?
somefile.h
#pragma once
namespace function {
void f1();
};
somefile.cpp
#include "somefile.h"
int main()
{
using namespace function;//compiler could not find this actually;
f1();
}
namespace function
{
void f1() {}
}
so I have to place everything into one .cpp file
Then just forget the #include and do one of the following:
a. put the declaration namespace function { void f1(); } above int main() and the definition (function body) below int main()
b. put the int main() last, so that you don't require additional declarations
I know in C++, we use :: to qualify the namespace for a variable or function, like myNamespace::a. But I notice some usages like ::myFunction(). Does it mean the function belongs to the global namespace?
If the code compiles, then yes, ::myFunction() is referencing the global declaration of myFunction.
This is most commonly used when a local definition shadows your global definition:
namespace local {
int myFunction() {}; // local namespace definition
};
int myFunction() {}; // global definition.
using namespace local;
int main() {
// myFunction(); // ambiguous two definitions of myFunction in current scope.
local::myFunction(); // uses local::myFunction();
::myFunction(); // uses global myfunction();
Yes, it means the variable, type or function following it must be available in the global namespace.
It can be used for example when something is shadowed by a local definition:
struct S {
int i;
};
void f() {
struct S {
double d;
};
S a;
::S b;
static_assert(sizeof(a) != sizeof(b), "should be different types");
}
I have two source files, a.cpp and b.cpp. In a.cpp, I have a function, foo:
namespace ns { void foo() { std::cout << "foo!"; } }
In b.cpp, I have another function in namespace ns in which I'd like to prototype and call foo:
namespace ns
{
void bar()
{
void foo();
foo();
}
}
While the above is syntactically valid, it leads the compiler to think that foo is in the global namespace (or at least that's what I've deduced from the linker errors I get when I do this). My first two ideas to fix that were void ns::foo(); and namespace ns { void foo(); }, but neither is valid. Is it possible to correctly prototype this function inside bar?
Note that I know I could simply move this to the file scope or a header file, there have been many questions asked about this, but I want to specifically prototype it inside another function. My compiler is MSVC 14.0 with the latest update.
EDIT: Based on some tests I've done and our discussion in the comments, I believe this is an MSVC bug. Compare:
namespace ns
{
void bar()
{
void foo(); // link error, MSVC assumes global namespace
foo();
}
void foo() { }
} // namespace ns
This fails, as stated previously. However, moving the prototype out of the function makes MSVC correctly place the prototyped function in the enclosing namespace:
namespace ns
{
void foo(); // all fine
void bar()
{
foo();
}
void foo() { }
} // namespace ns
The standard is clear about this point:
3.3.2/11: (..) Function declarations at block scope and variable declarations with the extern specifier at block scope refer to
declarations that are members of an enclosing namespace (...)
Consequently:
void bar()
{
void foo(); // should refer to ns::foo() according to 3.3.2/11
foo();
}
and the linking should refer to the separately compiled function which has the same signature:
1.3.17 signature: <function> name, parameter type list , and enclosing namespace (if any) [Note: Signatures are used as a basis for
name mangling and linking.—end note ]
This code does not compile:
class A;
void foo(A&) {
}
class A {
void foo() {
foo(*this); ///This does not compile
}
};
Errors:
error: no matching function for call to 'A::foo(A&)'
foo(*this);
^
note: candidate is:
note: void A::foo()
This can be solved by calling ::foo(*this);
However, let's consider the case we are in a namespace:
namespace bar {
class A;
void foo(A&) {
}
class A {
void foo() {
foo(*this); ///This does not compile
}
};
}
Is there any other way than calling explicitly bar::foo(*this);? I mean, is there any way to look up names in the next surrounding declarative region, i.e. the containing bar namespace?
The use case is similar to what seen here.
I mean, is there any way to look up names in the next surrounding declarative region,
i.e. the containing bar namespace?
No.
You can sort of do it the other way around:
void foo() {
using bar::foo;
foo(*this); /// OK now
}
Not within the method itself. However, you can do this in the .cpp file:
namespace bar {
namespace {
auto outerFoo = foo;
}
void A::foo() {
outerFoo(*this);
}
}
Note that the name outerFoo is a hidden implementation detail which cannot cause name collisions (since it's in an anonymous namespace).
Why does the following code prints different results on different compilers?
#include <iostream>
void foo() { std::cout << "::foo() \n"; }
namespace Foo
{
struct Bar
{
friend void foo() { std::cout << "Bar::foo() \n"; }
void bar() { foo(); }
void baz();
};
void Bar::baz() { foo(); }
}
int main()
{
Foo::Bar instance;
instance.bar();
instance.baz();
}
Output
gcc 4.7.2
::foo()
::foo()
MSVC-10.0
Bar::foo()
Bar::foo()
MSVC-11.0
error C3861: 'foo': identifier not found
error C3861: 'foo': identifier not found
Who is right? And why is it so?
I think gcc is right:
7.3.1.2/3 in C++11:
If a friend declaration in a non-
local class first declares a class or function the friend class or
function is a member of the innermost enclosing namespace. The name of
the friend is not found by unqualified lookup (3.4.1) or by qualified
lookup (3.4.3) until a matching declaration is provided in that
namespace scope (either before or after the class definition
C++03 has similar language in the same place.
I'm not sure why MSVC-11 fails to find ::foo, but I suppose you could read this text to mean that the name foo can't be looked up at all. I think the intended meaning is that the name in the innermost enclosing namespace can't be found, but the identically-spelled name in the outer scope can. But if Microsoft wants to argue the intended meaning I'm not the person they'd argue it with.
MSVC-10 is wrong, because it found a name that the standard specifically says is not found. So the explanation for the MSVC-11 behavior might be as simple as "it was reported as a bug in 10, they tried to fix it and went too far".
Anyway, the fix is to introduce a declaration of foo in namespace Foo:
namespace Foo
{
void foo(); // this is a matching declaration
struct Bar
{
friend void foo() { std::cout << "Bar::foo() \n"; }
void bar() { foo(); }
void baz();
};
void Bar::baz() { foo(); }
}
This makes gcc find the friend function. I haven't tested on any version of MSVC.