The following code:
variant<string> x = "abc";
cout << get<string>(x) << "\n";
works fine under g++ (version 7.2). However, when compiled under clang++ (version 5.0) using libstdc++, I get the following error in the get method:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/variant:238:46: fatal error: cannot cast 'std::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >' to its private base class 'std::__detail::__variant::_Variant_storage<false, std::
__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >'
return __get(std::in_place_index<_Np>, std::forward<_Variant>(__v)._M_u);
Is this a compiler bug, or is my code illegal in any way?
This is caused by clang bug 31852 (and also 33222), whose reproduction courtesy of Jonathan Wakely should look very relevant:
template<typename V> auto get(V&) { }
template<typename>
class variant
{
template<typename V> friend auto get(V&);
};
int main()
{
variant<int> v{};
get(v); // error: ambiguous
}
clang doesn't properly recognize friend declarations that have placeholder types. Which is exactly how libstdc++ implements std::get:
// Returns the typed storage for __v.
template<size_t _Np, typename _Variant>
constexpr decltype(auto) __get(_Variant&& __v)
{
return __get(std::in_place_index<_Np>, std::forward<_Variant>(__v)._M_u);
}
this accesses a private member of variant, but this function is properly declared a friend:
template<size_t _Np, typename _Vp>
friend constexpr decltype(auto) __detail::__variant::__get(_Vp&& __v);
libstdc++'s implementation is valid, clang just doesn't think __get is a friend.
Related
I have a class with a templated member function that takes a callable type as an argument and has a return type deduced from the return type of the supplied function using decltype with the trailing return type syntax. A minimal example is shown below.
#include <iostream>
#include <vector>
class point {
public:
std::vector<double> val;
point(double in) : val({in}) {};
template<typename T> auto eval(const T& in) -> decltype(in(val[0]));
};
template<typename T>
auto point::eval(const T& in) -> decltype(in(val[0])){
return in(val[0]);
}
int main(int argc, char *argv[]){
point pt(2.0);
auto f = [](double x){return x*x;};
std::cout << pt.val[0] << std::endl;
std::cout << pt.eval(f) << std::endl;
}
This code compiles and works as expected in clang++ and g++-5 but chokes with the following error in g++-6.
> g++-6 main.cpp -o test -std=c++11 -Wall main.cpp:13:6: error:
> prototype for 'decltype
> (in(0->((point*)this)->point::val.std::vector<_Tp,
> _Alloc>::operator[]<double, std::allocator<double> >())) point::eval(const T&)' does not match any in class 'point' auto
> point::eval(const T& in) -> decltype(in(val[0])){
> ^~~~~ main.cpp:9:35: error: candidate is: template<class T> decltype (in(0->((point*)this)->point::val.std::vector<_Tp,
> _Alloc>::operator[]<double, std::allocator<double> >())) point::eval(const T&)
> template<typename T> auto eval(const T& in) -> decltype(in(val[0]));
> ^~~~ main.cpp:9:35: error: 'decltype (in(0->((point*)this)->point::val.std::vector<_Tp,
> _Alloc>::operator[]<double, std::allocator<double> >())) point::eval(const T&) [with T = main(int, char**)::<lambda(double)>;
> decltype (in(0->((point*)this)->point::val.std::vector<_Tp,
> _Alloc>::operator[]<double, std::allocator<double> >())) = double]', declared using local type 'const main(int, char**)::<lambda(double)>',
> is used but never defined [-fpermissive] main.cpp:9:35: warning:
> 'decltype (in(0->((point*)this)->point::val.std::vector<_Tp,
> _Alloc>::operator[]<double, std::allocator<double> >())) point::eval(const T&) [with T = main(int, char**)::<lambda(double)>]'
> used but never defined make: *** [all] Error 1
The compiler error does not appear if the implementation is written inline, i.e.
template<typename T> auto eval(const T& in) -> decltype(in(val[0])){
return in(val[0]);
}
Additionally in c++14 using automatic return type deduction by changing the signature to
template<typename T> auto eval(const T& in);
works as expected.
Is this a gcc compiler bug or is clang incorrectly accepting the above code?
What if any is the difference between these function signatures?
Why does inlining the implementation make a difference?
Yeah, likely a gcc bug. A workaround is to do
template<typename T>
std::result_of<T(double)> point::eval(const T& in) {
that is because you are not explicitly instantiating template function definition. As far as I understand, it is not valid c++ code and compilers don't have to accept it. If you want to reproduce this error on other compilers, try moving point class to header file and point::eval definition into .cpp file. So you either have to explicitly instantiate this definition for every type of argument (which is impossible with lambdas), or (as I suggest) don't use out-of-line templates unless urgently required.
I took the following example from http://en.cppreference.com/w/cpp/language/function_template#Function_template_overloading
and clang (3.4) seems to be handling it just fine, while g++ (4.8.3) gives an 'ambiguous overload' error:
struct A {};
template<class T> struct B {
template<class R> void operator*(R&){ cout << "1" << endl; } // #1
};
template<class T, class R> void operator*(T&, R&) { cout << "2" << endl;} // #2
int main() {
A a;
B<A> b;
b * a; //prints 1
}
clang correctly prints 1 (as expected according to cppreference), while g++ gives this error:
test_templates.cpp: In function ‘int main()’:
test_templates.cpp:13:5: error: ambiguous overload for ‘operator*’ (operand types are ‘B<A>’ and ‘A’)
b * a; //prints 1
^
test_templates.cpp:13:5: note: candidates are:
test_templates.cpp:7:26: note: void B<T>::operator*(R&) [with R = A; T = A]
template<class R> void operator*(R&){ cout << "1" << endl; } // #1
^
test_templates.cpp:9:33: note: void operator*(T&, R&) [with T = B<A>; R = A]
template<class T, class R> void operator*(T&, R&) { cout << "2" << endl;} // #2
Is g++ actually misbehaving here?
This example is taken from the standard (this is the draft for c++11).
14.5.6.2 Partial ordering of function templates paragraph 3 example:
struct A { };
template<class T> struct B {
template<class R> int operator*(R&); // #1
};
template<class T, class R> int operator*(T&, R&); // #2
// The declaration of B::operator* is transformed into the equivalent of
// template<class R> int operator*(B<A>&, R&); // #1a
int main() {
A a;
B<A> b;
b * a; // calls #1a
}
So, the standard itself pretty much say this is legal code. I could copy-paste rules, but one might as well click link and jump to the relevant place. My point is only to prove this is a proper compilable code as defined by the standard.
For what it's worth on my debian clang 3.5.0 compiled it right away, clang 3.4.2 had to be executed with -std=c++11, g++ 4.9.1 reported ambiguity in all cases (I even tried 1y).
I am puzzled by clang behaviour, though. I thought it might have been ambiguous in earlier versions of c++, the rule to disambiguate was added as a part of c++11 and g++ didn't keep up. But clang 3.5 compiles it even with -std=c++98.
That call is ambiguos. GCC is right.
§13.5.2/1
Thus, for any binary operator #, x#y can be interpas either
x.operator#(y) or operator#(x,y). If both forms of the operator
function have been declthe rules in 13.3.1.2 determine which, if any,
interpretation is used.
And in this case, we do have both the member and nonmember function. The built-in version is not included because the left hand operator has class type.
If you called the operator explicitly, there would be no ambiguity. However, when the call is done through an operator (thus implicitly) there is nothing which can distinguish between member and nonmember, therefore they're both viable functions which, in this case, leads to an ambiguous function call.
Previous versions of clang report it as ambiguous as well: http://goo.gl/OWsJUv
Here's a sample program:
#include <type_traits>
#include <stdio.h>
template <typename X>
struct test
{
operator int() const { puts("?"); return 0; }
template <typename T, typename = typename std::enable_if<std::is_same<X, void*>::value, T>::type>
operator T() const { puts("T"); return 0; }
};
int main()
{
test<void*> t;
char* c = (char*)t;
switch (t)
{
case 0: break;
}
return 0;
}
And this is the error that g++-4.7 gives
user#user:~$ g++-4.7 -std=c++0x test.cpp
test.cpp: In function ‘int main()’:
test.cpp:13:14: error: ambiguous default typeconversion from ‘test<void*>’
test.cpp:13:14: error: candidate conversions include ‘template<class T, class> test::operator void*() const [with T = T; <template-parameter-2-2> = <template-parameter-1-2>; X = void*]’
g++ 4.6 compiles it without errors and different operators are actually called.
Is there a way to make this work under g++ 4.7?
UPDATE: actually it works in 4.6 without any enable_if at all... so the question still applies but I'm now not sure if enable_if will help.
If you add an explicit cast to int here:
switch ((int)t)
Then it should compile.
I think it's complaining about the conversion being ambiguous since there exists more than one type that can hold a 0 value.
I'm using g++ 4.8 though.
I found at least one "acceptable" solution:
#define switch(x) \
switch( (typename switch_type<__typeof(x)>::type)(x) )
which switch_type trait can be extended to resolve ambiguity for specific app-related types (property types).
Assume the following code:
#include <iostream>
template<typename T>
struct Link
{
Link(T&& val) : val(std::forward<T>(val)) {}
T val;
};
template<typename T>
std::ostream& operator<<(std::ostream& out, const Link<T>& link)
{
out << "Link(" << link.val << ")";
return out;
}
template<typename T>
auto MakeLink(T&& val) -> Link<T>
{
return {std::forward<T>(val)};
}
namespace Utils {
template<typename Any>
constexpr auto RemoveLinks(const Any& any) -> const Any&
{
return any;
}
template<typename T>
constexpr auto RemoveLinks(const Link<T>& link) -> decltype(RemoveLinks(link.val))
{
return RemoveLinks(link.val);
}
} /* Utils */
int main()
{
int k = 10;
auto link = MakeLink(MakeLink(k));
std::cout << link << std::endl;
std::cout << Utils::RemoveLinks(link) << std::endl;
}
For some reason I can't understand, it generates the following compilation errors with g++-4.8:
/home/allan/Codes/expr.cpp: In instantiation of ‘constexpr decltype (Utils::RemoveLinks(link.val)) Utils::RemoveLinks(const Link<T>&) [with T = int&; decltype (Utils::RemoveLinks(link.val)) = const int&]’:
/home/allan/Codes/expr.cpp:88:32: required from ‘constexpr decltype (Utils::RemoveLinks(link.val)) Utils::RemoveLinks(const Link<T>&) [with T = Link<int&>; decltype (Utils::RemoveLinks(link.val)) = const int&]’
/home/allan/Codes/expr.cpp:100:41: required from here
/home/allan/Codes/expr.cpp:88:32: error: invalid initialization of reference of type ‘const Link<int&>&’ from expression of type ‘const int’
return RemoveLinks(link.val);
^
/home/allan/Codes/expr.cpp:89:1: error: body of constexpr function ‘constexpr decltype (Utils::RemoveLinks(link.val)) Utils::RemoveLinks(const Link<T>&) [with T = int&; decltype (Utils::RemoveLinks(link.val)) = const Link<int&>&]’ not a return-statement
}
^
/home/allan/Codes/expr.cpp: In function ‘constexpr decltype (Utils::RemoveLinks(link.val)) Utils::RemoveLinks(const Link<T>&) [with T = int&; decltype (Utils::RemoveLinks(link.val)) = const int&]’:
/home/allan/Codes/expr.cpp:89:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
while clang 3.3 gives:
test.cc:34:12: error: reference to type 'const Link<int &>' could not bind to an lvalue of type 'const int'
return RemoveLinks(link.val);
^~~~~~~~~~~~~~~~~~~~~
test.cc:46:25: note: in instantiation of function template specialization 'Utils::RemoveLinks<Link<int &> >' requested here
std::cout << Utils::RemoveLinks(link) << std::endl;
If, however, the namespace Utils is removed, then it compiles without errors (both gcc and clang), and execution outputs:
Link(Link(10))
10
Why defining those template functions (RemoveLinks) in a namespace causes such errors?
This problem is a result of an issue with the point of declaration (1) combined with dependent name lookup (2).
(1) In the declaration
template<typename T>
constexpr auto RemoveLinks(const Link<T>& link) -> decltype(RemoveLinks(link.val))
the name RemoveLinks, or more precisely, this overload of RemoveLinks, is only visible after the complete declarator according to [basic.scope.pdecl]/1. The trailing-return-type is part of the declarator as per [dcl.decl]/4. Also see this answer.
(2) In the expression RemoveLinks(link.val), the name RemoveLinks is dependent as per [temp.dep]/1, as link.val is dependent.
If we now look up how dependent names are resolved, we find [temp.dep.res]:
In resolving dependent names, names from the following sources are considered:
Declarations that are visible at the point of definition of the template.
Declarations from namespaces associated with the types of the function arguments both from the instantiation context and from the definition context.
The first bullet doesn't find the second overload of RemoveLinks because of the point of declaration (1). The second one doesn't find the overload because the namespace Util is not associated with any argument. This is why putting everything in the global namespace or in the namespace Util works as expected (Live example).
For the same reason, using a qualified-id in the trailing-return-type (like -> decltype(Util::RemoveLinks(link.val)) doesn't help here.
I tried compiling the sample code above with GCC 4.8.1, with clang and also Intel icpc and got the same error messages as you.
I am able to get it to successfully compile without trouble if I revise the signature of the template specialization from:
template<typename T>
constexpr auto RemoveLinks(const Link<T>& link) -> decltype(RemoveLinks(link.val))
and make the return type as const. This might cause a compiler warning since the const there is meaningless, but that can be ignored. I tested it and it works fine for me with gcc, but not icpc or clang:
template<typename T>
constexpr auto RemoveLinks(const Link<T>& link) -> decltype(RemoveLinks(link.val)) const
I found the error message (with the original code) from Intel icpc to be the most informative:
code.cc(48): error: template instantiation resulted in unexpected function type of "auto (const Link<Link<int &>> &)->const int &" (the meaning of a name may have changed since the template declaration -- the type of the template is "auto (const Link<T> &)->decltype((<expression>))")
std::cout << Utils::RemoveLinks(link) << std::endl;
^
detected during instantiation of "Utils::RemoveLinks" based on template argument <Link<int &>> at line 48
Unfortunately, the above answer is more of a workaround for gcc rather than an answer to your question. I'll update this if I have anything more / better to add.
EDIT
It appears that decltype(RemoveLinks(link.val)) is actually following the recursion so that it returns int& rather than Link.
EDIT #2
There have been reported bugs in LLVM about crashes caused by decltype recursion problems. It seems that this is definitely a bug of sorts, but one that seems to be present in multiple implementations of C++.
The problem can be fixed quite easily if you create a an alias for type T in the link struct and have decltype refer to the alias rather than to the return type. This will eliminate the recursion. As follows:
template<typename T>
struct Link
{
Link(T&& val) : val(std::forward<T>(val)) {}
using value_type = T;
T val;
};
And then the RemoveLinks signature is changed accordingly to refer to this alias:
template<typename T>
constexpr auto RemoveLinks(const Link<T>& link) -> decltype(links.value_type)
This code successfully builds on all 3 compilers.
I will file some bug reports with the compilers to see if there's anything they can do about it.
Hope this helps.
I just upgraded to GCC 4.8 and some variadic template code no longer compiles correctly. I've created a minimal example below:
#include <tuple>
#include <iostream>
template <class T, class ... OtherT>
void something( std::tuple<T, OtherT...> & tup )
{
std::cout << std::get<1>(tup) << std::endl;
}
int main()
{
std::tuple<int, char, bool> myTuple(3, 'a', true);
// Compiles OK in GCC 4.6.3 but NOT 4.8
something<int, char, bool>( myTuple );
// Compiles OK in GCC 4.8 but NOT 4.6.3
something<int, bool, char>( myTuple );
return 0;
}
The output of this will be (if commenting out the incorrect version for GCC 4.6.3/4.8)
'a'.
The error produced by GCC 4.6.3 is:
./test.cpp: In function ‘int main()’:
./test.cpp:18:39: error: no matching function for call to ‘something(std::tuple<int, char, bool>&)’
./test.cpp:18:39: note: candidate is:
./test.cpp:5:6: note: template<class T, class ... OtherT> void something(std::tuple<_Head, _Tail ...>&)
The error produced by GCC 4.8 is:
./test.cpp: In function ‘int main()’:
./test.cpp:15:39: error: no matching function for call to ‘something(std::tuple<int, char, bool>&)’
something<int, char, bool>( myTuple );
^
./test.cpp:15:39: note: candidate is:
./test.cpp:5:6: note: template<class T, class ... OtherT> void something(std::tuple<_El0, _El ...>&)
void something( std::tuple<T, OtherT...> & tup )
^
./test.cpp:5:6: note: template argument deduction/substitution failed:
./test.cpp:15:39: note: mismatched types ‘bool’ and ‘char’
something<int, char, bool>( myTuple );
It seems like in GCC 4.8, variadic template types are reversed when expanded, though oddly enough they don't "really" get reversed as proved by the output - it will be 'a' regardless of the ordering. Clang 3.3 agrees with the GCC 4.6.3 output.
Is this a bug in GCC 4.8 or something else?
EDIT: added a bug report to GCC here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774
This looks like a bug to me, GCC 4.8.0 and GCC 4.7.2 seem to be affected. Clang 3.2 and GCC 4.6.3 agree that the first call to something is the correct one and I really fail to see how GCC 4.7.2+ can consider the second call to be acceptable.
I'd say: Report a bug against GCC.
Update: I added a minimalistic example to the GCC bug report, just to help them and prove that it's a pure compiler bug and has nothing to do with std::tuple. Here's the reduced code:
template< typename... > struct X {};
template< typename T, typename... Ts >
void f( X< T, Ts... >& ) {}
int main()
{
X< int, bool, char > t;
f< int, char, bool >(t);
}
Update 2: It's now fixed for GCC 4.7.3, GCC 4.8.1 and GCC 4.9 - kudos to the GCC team for an insanely fast fix!