The code below compiles fine with clang, but does not compile with GCC (tried 4.1.2, 4.5.4 and 4.7.2):
template <typename T>
struct A
{
struct B { };
};
template <typename T>
bool operator==(typename A<T>::B const& b, T const& t);
enum { BAR };
template <typename T>
bool test()
{
return 0 == BAR;
}
The error message from GCC 4.7.2 is:
a.cpp: In instantiation of ‘struct A<<anonymous enum> >’:
a.cpp:12:6: required by substitution of ‘template<class T> bool operator==(const typename A<T>::B&, const T&) [with T = <anonymous enum>]’
a.cpp:19:17: required from here
a.cpp:6:12: error: ‘<anonymous enum>’ is/uses anonymous type
a.cpp:6:12: error: trying to instantiate ‘template<class T> struct A<T>::B’
a.cpp:6:12: error: ‘<anonymous enum>’ is/uses anonymous type
a.cpp:6:12: error: trying to instantiate ‘template<class T> struct A<T>::B’
Is GCC correct in rejecting the code, or am I hitting its bug?
P.S. I've seen this error while trying to build one of opensource projects. I tried to make smallest possible example that reproduces it.
It is not valid C++ according to the original standard:
14.3.1 of the standard says:
2 A local type, a type with no linkage, an unnamed type or a
type compounded from any of these types shall not be used as a
template argument for a template type-parameter. [Example: ...
However I believe this was restriction was removed by the latest C++11 standard. That may explain why some compilers accept it while others reject it.
Related
The following code attempts to partially specialize a class using a concept and add a method to the specialization, but it is rejected by clang 11.0.0:
#include <concepts>
template <typename T> // note: previous template declaration is here
struct S {};
template <std::integral T>
struct S<T>
{
void f();
};
template <std::integral T> // error: type constraint differs in template redeclaration
void S<T>::f()
{
}
clang gives the error message:
<source>:14:16: error: type constraint differs in template redeclaration
template <std::integral T>
^
<source>:3:11: note: previous template declaration is here
template <typename T>
(see https://godbolt.org/z/Wv1ojK). Why is this code wrong? Or is this a bug in clang? (FWIW, this code is accepted by gcc trunk and by MSVC 19.28, although that's no guarantee of correctness.)
This is definitely a CLANG bug. It is already filed - #48020.
Please, have a look at this small sample code
#include <type_traits>
struct base {
template <typename T>
int func(T);
};
struct derived: base {
using base::func;
template <typename T, std::enable_if_t<std::is_same_v<T,const char*>>* = nullptr>
int func(T);
};
auto x = derived().func(1);
It compiles fine with gcc and icc, it doesn't with clang, which complains like this:
<source>:17:20: error: no matching member function for call to 'func'
auto x = derived().func(1);
~~~~~~~~~~^~~~
<source>:13:9: note: candidate template ignored: requirement 'std::is_same_v<int, const char *>' was not satisfied [with T = int]
int func(T);
^
As if no using-declaration were added to struct derived. If I weren't using templates, I'd for sure know that this would be clang's problem. However, I am not sure the fact I'm using templates and SFINAE implies different rules got to be used, so here's my question: which compiler is right? Clang, or gcc and icc?
Here's a working example of the issue on godbolt: https://godbolt.org/z/xv98SP
I want to use the standard code to write the utils like std::is_union,we know class type can not extends union type,it's error,so some code like these
#include <iostream>
template<typename T>
class class_type_can_extends :public T{
public:
using type = void;
};
template<typename T,typename U = void>
struct is_not_union:std::false_type {
};
template<typename T>
struct is_not_union < T, std::void_t<typename class_type_can_extends <T>::type >> :std::true_type {
};
class c_data{
};
union u_data{
};
int main(){
/*#1*/ std::cout<< is_not_union<c_data>::value<<std::endl; /*print true*/
/*#2*/ std::cout<< is_not_union<u_data>::value<<std::endl; /*this code make
all complier error*/
}
g++ print error:
main.cpp: In instantiation of ‘class class_type_can_extends<u_data>’:
main.cpp:26:43: recursively required by substitution of ‘template<class T> struct is_not_union<T, std::void_t<typename class_type_can_extends<T>::type> > [with T = u_data]’
main.cpp:26:43: required from here
main.cpp:3:7: error: base type ‘u_data’ fails to be a struct or class type
class class_type_can_extends :public T {
clang print error:
main.cpp:3:38: error: unions cannot be base classes
class class_type_can_extends :public T {
~~~~~~~^
main.cpp:14:47: note: in instantiation of template class 'class_type_can_extends<u_data>' requested here
struct is_not_union < T, std::void_t<typename class_type_can_extends <T>::type >> :std::true_type {
^
main.cpp:26:23: note: during template argument deduction for class template partial specialization 'is_not_union<T,
std::void_t<typename class_type_can_extends<T>::type> >' [with T = u_data]
/*#2*/ std::cout << is_not_union<u_data>::value << std::endl; /*this code make
^
main.cpp:26:23: note: in instantiation of template class 'is_not_union<u_data, void>' requested here
1 error generated.
vs:
error C2569
why #2 code make complier error,The complier would be using SFINAE rules on #2 code(substituted T by "u_data" ,then Failed ),and to chose primary template?why the sfinae not effective here,may be a bug here?
From cppreference:
Only the failures in the types and expressions in the immediate context of the function type or its template parameter types or its explicit specifier (since C++20) are SFINAE errors. If the evaluation of a substituted type/expression causes a side-effect such as instantiation of some template specialization, generation of an implicitly-defined member function, etc, errors in those side-effects are treated as hard errors
SFINAE applies on immediate context, here you have a hard error failure.
In typename class_type_can_extends<T>::type, SFINAE applies if type doesn't exist, not if instantiation of class_type_can_extends<T> fails.
Notice that we cannot distinguish between union and class types using only standard C++
(without std::is_union). Most compilers provide intrinsics for that.
This code results in an error in gcc6 (but works fine in gcc 4.8, 5.2 and clang 3.6):
template <typename T>
struct outer
{
template <typename U>
struct inner
{
};
};
template <typename T>
struct is_inner_for
{
template <typename Whatever>
struct predicate
{
static constexpr bool value = false;
};
template <typename U>
struct predicate<typename outer<T>::template inner<U>>
{
static constexpr bool value = true;
};
};
static_assert(
is_inner_for<int>::template predicate<
outer<int>::inner<double>
>::value,
"Yay!"
);
The error is:
main.cpp:22:9: error: template parameters not deducible in partial specialization:
struct predicate<typename outer<T>::template inner<U>> : std::true_type
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
main.cpp:22:9: note: 'U'
^~~~~~~~~~~~~
Commandline is:
g++ -std=c++1y -c main.cpp
See godbolt output here.
I have filed a bug report with gcc here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
However it was marked as invalid (I believe wrongly). The outer<T> that is used inside predicate is a concrete type at that point, so it is not a non-deduced context.
Is there anything in the standard that prevents this being valid c++ code?
I suspect this is a bug in gcc 6.0, and an incorrect warning in clang 3.9 (the warning is weird - because the warning implies that the partial specialization would not be chosen, but if it were not chosen, the static assert would trigger).
From [temp.class.spec.match]:
A partial specialization matches a given actual template argument list if the template arguments of the
partial specialization can be deduced from the actual template argument list
Can we deduce U in typename outer<T>::template inner<U> from outer<int>::inner<double>?
From [temp.deduct.type]:
If a template parameter is used only in non-deduced
contexts and is not explicitly specified, template argument deduction fails.
The non-deduced contexts are:
— The nested-name-specifier of a type that was specified using a qualified-id.
— [...]
But the nested-name-specified here is typename outer<T>, which does not contain the type we're trying to deduce. None of the other non-deduced contexts apply. So deduction should succeed here.
Consider the following equivalent situation:
#include <utility>
template <class >
struct outer
{
template <class U> struct inner {};
};
template <class T>
struct bar {
template <class U> std::false_type foo(U const&);
template <class U> std::true_type foo(typename outer<T>::template inner<U> const&);
};
int main() {
static_assert(decltype(bar<int>{}.foo(outer<int>::inner<double>{}))::value, "!");
}
Both gcc 6.0 and clang 3.9 compile this code without warning - but this is the same sort of deduction that would happen in the partial specialization in the original example.
template <typename T>
class rp {
};
template <template <typename> class P>
struct b {
template <class, template <typename> class FriendP>
friend void f(b<FriendP> from);
};
template <class, template <typename> class P>
void f(b<P> from) {
}
int main() {
b<rp> v;
f<int>(v);
return 0;
}
Clang 3.3 (svn) compiles fine, while GCC 4.8 rejects it:
main.cpp: In function 'int main()':
main.cpp:17:10: error: call of overloaded 'f(b<rp>&)' is ambiguous
f<int>(v);
^
main.cpp:17:10: note: candidates are:
main.cpp:12:6: note: void f(b<P>) [with <template-parameter-1-1> = int; P = rp]
void f(b<P> from) {
^
main.cpp:8:17: note: void f(b<FriendP>) [with <template-parameter-2-1> = int; FriendP = rp; P = rp]
friend void f(b<FriendP> from);
^
I wonder why GCC claims f to be overloaded. So I guess it's a GCC bug.
Which compiler is right?
Friend injection does no longer exist in the c++ standard, see this for informations about this. However, since the friend function declared inside struct b "acts" on a parameter of type "b", the function is found via ADL (argument-dependant lookup). When this happens 2 different functions having the same signature are declared, and the compiler complains.
This is probably what you meant:
template <template <typename> class P>
struct b {
template <class, template <typename> class FriendP>
friend void f(b<FriendP> from){};
};
but don't use this in real code as it is, since "duplicate function" problems can, as you see, easily arise (proper use of namespaces can be of help with this respect).
The code can be tested here
A good reference for the use (as well as a good real-life example of why they are needed) of template friend functions can be found in item 46 of Effective c++