The following example demonstrates the problem I encountered in VC++ 2010:
class Foo
{
template<class T>
static T foo(T t) { return t; }
public:
void test()
{
auto lambda = []() { return foo(1); }; // call to Foo::foo<int>
lambda();
}
};
VC++ produces: error C3861: 'foo': identifier not found
If I qualify the call to foo: Foo::foo(1); then this example compiles with a warning:
warning C4573: the usage of 'Foo::foo' requires the compiler to capture 'this' but the current default capture mode does not allow it
What does the standard say about this case? Should unqualified name be found? Does the qualified name require capturing this?
Microsoft has been seeing this problem reported in a number of cases. See:
Scope Resolution with lambdas interferes with namespace and type resolution
Template resolution in lambdas
As you've found out, explicit resolution allows it to find the name. There is an additional warning about this which is also a compiler error (name resolution doesn't require access to this, though I can see how a compiler implementation might require it) - it's a separate bug though. Microsoft has confirmed this to be a bug and have apparently prepared a fix for the next release.
The following compiles fine. It seems to me that this must just be a VS bug with templates.
struct Foo {
static void foo() {}
void bar() {
auto f = []() { foo(); };
f();
}
};
Related
#include <iostream>
struct A {
void test() { std::cout << "A\n"; }
};
struct B : A {
void test() { std::cout << "B\n"; }
};
struct C : B {
using A::test;
using B::test;
};
int main() {
C().test(); // Is this ambiguous?
return 0;
}
In this example, g++ 8.1.0 compiles successfully and calls test() from B.
clang++ 3.8.0 reports: error: call to member function 'test' is ambiguous.
Which is correct? If it is g++, what is the rule that picks B::test over A::test?
I believe Clang is correct.
According to [namespace.udecl]/13:
Since a using-declaration is a declaration, the restrictions on declarations of the same name in the same declarative region ([basic.scope]) also apply to using-declarations.
Since you can't declare two identical member functions, the same applies to using declarations.
GCC lets it compile and test() call becomes the first declaration. In the example given, it'll call the A::test(). But ISO C++ defines it as ambiguous. Visual Studio and clang won't let you compile it. Additionally, this the VS error message: 'B::test': ambiguous call to overloaded function. In my opinion, GCC is wrong by letting it compile.
I'm trying to compile the MSVC standard library using Clang. But it fails because the standard library uses explicit template function specialization at class scope.
This is a MS extension, and apparently not available in Clang.
Here's a simple example that compiles fine with MSVS, but not with Clang.
template<class T>
class A
{
public:
A()
{
foo((T)0, 0);
}
template<class T2>
void foo(T2, void* p) {}
template<>
void foo<bool>(bool, void* p)
{
t = (T)p;
}
T t;
};
int main()
{
A<bool> a;
return 0;
}
What should I do to get this feature to work when using Clang, so I can compile the MSVC standard library?
This is the compile error I get:
warning: explicit specialization of 'foo' within class scope is a Microsoft extension [-Wmicrosoft]
void foo<bool>(bool, void* p)
error: expected ';' after expression
t = (T)p;
^
;
error: no member named 'T' in 'A<bool>'
t = (T)p;
^
I think you'll have three possibilities:
Rewrite the MSVC library so it does not use that extension (could be fun, but time consuming...)
Fix that MS-extension in Clang (could be even more fun and time consuming...)
Do the sane thing: use each library with the compiler it was made for (how boring...)
Update from this testing code for Clang I assume that it is already implemented, but it does not expect an explicit template parameter:
template<>
void foo(bool, void* p)
{
t = (T)p;
}
Its probably a bug in Clang's implementation of that extension.
AFAIK you will have to extend clang to support explicit specialization within class scope. I don't think there is any way around it, unless you want to modify the library.
I was surprised by the fact that GCC does not consider the call to foo() in the following program ambiguous:
#include <iostream>
struct B1 { bool foo(bool) { return true; } };
struct B2 { bool foo(bool) { return false; } };
struct C : public B1, public B2
{
using B1::foo;
using B2::foo;
};
int main()
{
C c;
// Compiles and prints `true` on GCC 4.7.2 and GCC 4.8.0 (beta);
// does not compile on Clang 3.2 and ICC 13.0.1;
std::cout << std::boolalpha << c.foo(true);
}
The above function call compiles and returns true on GCC 4.7.2 and GCC 4.8.0 (beta), while it won't compile (as I would expect) on Clang 3.2 and ICC 13.0.1.
Is this a case of "no diagnostic required", or is it a bug in GCC? References to the C++11 Standard are encouraged.
§7.3.3/3:
In a using-declaration used as a member-declaration, the nested-name-specifier shall name a base class of the class being defined. If such a using-declaration names a constructor, the nested-name-specifier shall name a direct base class of the class being defined; otherwise it introduces the set of declarations found by member name lookup (10.2, 3.4.3.1).
¶14:
… [ Note: Two using-declarations may introduce functions with the same name and the same parameter types. If, for a call to an unqualified function name, function overload resolution selects the functions introduced by such using-declarations, the function call is ill-formed.
¶16:
For the purpose of overload resolution, the functions which are introduced by a using-declaration into a
derived class will be treated as though they were members of the derived class.
So, the using declarations are legal, but the functions are peers in the same overload set, as you said, and the program is ill-formed.
The call to foo(true) in your program is, as you say, clearly ambiguous; furthermore, it is ambiguous according to the algorithm presented in §10.2 and consequently, it should be flagged on use. (Flagging the using declaration would be incorrect; 10.2(1) clearly states that ambiguous uses of names are flagged on lookup, not on declaration.)
It's interesting to contrast this program with a similar one, which is the subject of a a recognized gcc bug (slightly modified from that bug report to make the parallel clearer):
#include <iostream>
struct A {
static int foo() {return 1;}
static int foo(char) { return 2;}
};
struct B1 : A {
// using A::foo;
};
struct B2 : A {
// using A::foo;
};
struct C : B1, B2 {
// using B1::foo;
// using B2::foo;
};
int main()
{
std::cout << C::foo();
}
The above program is correct; despite the diamond inheritance, foo is a static member of A, so it is not ambiguous. In fact, gcc compiles it without trouble. However, uncommenting the two instances of using A::foo, which does not change anything about either foo, causes gcc to produce the oddly reduplicated error noted in the bug report. Uncommenting the two using declarations inside C, which presumably triggers the other bug which is the subject of this question, then masks the static function bug and causes the program to compile again.
clang seems to handle all possible variants of this program, for what it's worth.
Finally, note that an explicitly declared foo(bool) within C (in the original program) will win out over any foo(bool) brought into C's scope by using declarations. I suspect that both of these bugs are the result of bad bookkeeping while trying to keep track of the various function declarations in each class's scope and their individual provenance (as a sequence of using declarations and function declarations).
The following gives the error 'one': identifier not found in VS2010 and VS2012
int main()
{
struct one {};
[](){ return one(); }();
}
And with a slight tweak...
int main()
{
struct one {};
[](){ one uno; return uno; }();
}
VS2010/VS2012 both have a compiler crash from this code.
So, the question is (ignoring the compiler crash), are lambas supposed to be able to have visibility of local classes?
Yes, VS is incorrect. From 5.1.2p7:
[...] for purposes of name lookup, [...] the compound-statement is considered in the context of the lambda-expression.
I have the following code snippet:
void foo(double a) {}
namespace bar_space
{
struct Bar {};
void foo(Bar a) {}
}
foo(double) is a general function from a library.
I have my own namespace bar_space with my own struct, Bar. I would like to implement an overloading of foo() for Bar, thus making Bar more similar to the built-in types.
Trouble appears when I attempt to call the original foo(double) from within the namespace:
namespace bar_space
{
void baz()
{
foo(5.0); // error: conversion from ‘double’ to non-scalar type ‘ssc::bar_space::Bar’ requested
}
}
This fails to compile on gcc on both my Fedora and Mac.
Calling
foo(5.0)
from outside the namespace or using
namespace bar_space
{
::foo(5.0)
}
works ok, but this doesnt make my new function quite as nice as I had hoped for (other developers are also working inside bar_space).
Is bar_space hiding the original function? Is there a way to make foo(5.0) callable from within bar_space without explicit scoping (::)? Any help is appreciated.
In C++, there is a concept called name hiding. Basically, a function or class name is "hidden" if there is a function/class of the same name in a nested scope. This prevents the compiler from "seeing" the hidden name.
Section 3.3.7 of the C++ standard reads:
A name can be hidden by an explicit
declaration of that same name in a
nested declarative region or derived
class (10.2)
So, to answer your question: in your example void foo(double a); is hidden by void bar_space::foo(Bar a); So you need to use the :: scoping operator to invoke the outer function.
However, in your sample code you could use something like that
namespace bar_space
{
using ::foo;
void baz()
{
Bar bar;
foo(5.0);
foo(bar);
}
}
Yes, bar_space is hiding the original function and no, you can't make foo(5.0) callable from whithin bar_space without explicit scoping if foo(double) is defined in the global namespace.