The following code doesn't link Clang 10 but succeed with GCC and Clang 9:
#include <queue>
template <typename T>
class A
{
public:
void f();
private:
std::queue<int> q;
};
template <typename T>
void A<T>::f()
{
q = {};
}
template class A<int>;
int main()
{
return 0;
}
What I get from the compiler is:
Online example
/opt/compiler-explorer/gcc-9.3.0/lib/gcc/x86_64-linux-gnu/9.3.0/../../../../x86_64-linux-gnu/bin/ld: /tmp/example-f70f65.o: in function `A<int>::f()':
/home/ce/<source>:16: undefined reference to `std::queue<int, std::deque<int, std::allocator<int> > >::~queue()'
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
Compiler returned: 1
It works if I replace std::queue with std::vector, std::deque or std::set; or if I remove the explicit template instantiation.
It also works if I remplace q = {} with the full constructor call q = std::queue<int>{}.
Is this code not standard or is it a compiler/libc++ bug?
I am not sure why you get such linker error, maybe its some unique issue with godbolt. If you try to compile your code with coliru : https://coliru.stacked-crooked.com/a/ac9c188334f858d8 you will get a compiliation time error indicating that you try to use list initialization of your queue:
main.cpp:16:7: error: no viable overloaded '='
q = {};
~ ^ ~~
main.cpp:19:16: note: in instantiation of member function 'A<int>::f' requested here
template class A<int>;
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/bits/stl_queue.h:96:11: note: candidate function (the implicit move assignment operator) not viable: cannot convert initializer list argument to 'std::queue<int, std::deque<int, std::allocator<int> > >'
class queue
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/bits/stl_queue.h:96:11: note: candidate function (the implicit copy assignment operator) not viable: cannot convert initializer list argument to 'const std::queue<int, std::deque<int, std::allocator<int> > >'
1 error generated.
queue does not allow list initialization with initializer_list, there is SO on this here: Why can't I construct a queue/stack with brace-enclosed initializer lists? (C++11)
But it appears you can make your code compile (at least on coliru, I tried on godbolt with no success) if you use libc++ (-stdlib=libc++) : https://coliru.stacked-crooked.com/a/df9d859a239843cf
It might not give exact answer to your question, but I it was too long for a comment. Also you might find similar thread here : https://github.com/envoyproxy/envoy/issues/9106
[edit]
Interesting, after reseting godbolt UI and entering code again with the same configuration (https://godbolt.org/z/TzE9h9) everything works ok.
Related
This question is spawned from
Passing a member function pointer to an overloaded class method into a template function.
You need not read that to understand this question. Probably both the questions will have the same answer.
I am getting compiler error for below simple code.
#include<set>
template<typename Return, typename T>
T ReceiveFuncPtr (Return (T::*Method)(const int&))
{
T obj; // Found and declared an object of actual container class
(obj.*Method)(1); // Some processing
return obj; // Returned that container class object with RVO
}
int main ()
{
ReceiveFuncPtr(&std::set<int>::insert); // ERROR
}
The error is interesting:
In function 'int main()':
error: no matching function for call to 'ReceiveFuncPtr(<unresolved overloaded function type>)'
ReceiveFuncPtr(&std::set<int>::insert); // ERROR
^
note: candidate is:
note: template<class Return, class T> T ReceiveFuncPtr(Return (T::*)(const int&))
T ReceiveFuncPtr (Return (T::*Method)(const int&))
^
note: template argument deduction/substitution failed:
note: mismatched types 'const int&' and 'std::initializer_list<int>'
ReceiveFuncPtr(&std::set<int>::insert); // ERROR
^
note: mismatched types 'const int&' and 'std::set<int>::const_iterator {aka std::_Rb_tree_const_iterator<int>}'
note: mismatched types 'const int&' and 'std::set<int>::const_iterator {aka std::_Rb_tree_const_iterator<int>}'
note: mismatched types 'const int&' and 'std::set<int>::value_type&& {aka int&&}'
note: couldn't deduce template parameter 'Return'
If you look at the notes closely then it appears that compiler is matching all the other methods except the right one! In this case compiler should have matched insert(const std::set<int>::value_type&) aka const int&. If I change the ReceiveFuncPtr() to match some other overload, it will again fail by skipping that overload.
To debug this situation, I created handcrafted version of std::set. But that compiles fine:
template<typename T, typename T2 = void>
struct MySet
{
std::pair<T,bool> insert (const T& i) { return std::pair<T,bool>(T(),true); }
std::pair<T,bool> insert (T&& i) { return std::pair<T,bool>(T(),true); }
void insert (std::initializer_list<T> i) { return false; }
}
int main ()
{
ReceiveFuncPtr(&MySet<int>::insert); // OK
}
After surfing, I came across this post:
What are the rules for function pointers and member function pointers to Standard functions?
Though it's related , it doesn't solve problem.
Question: Why member function substitution fails in case of standard library method when the the same thing passes for handwritten class method?
Update:
After looking at the correct answer, I am sure that insert cannot be used. The only way would be ugly typecasting which is an overkill for this problem.
One elegant solution is to use std::set<int>::emplace<const int&> which has only templated version unlike insert which has mix of template and non-template versions.
Call the function as below:
ReceiveFuncPtr(&std::set<int>::emplace<const int&>);
Above compiles fine.
The problem isn't with the insert functions you showed in MySet. The problem is with one of the ones you omitted. Specifically:
template< class InputIt >
void insert( InputIt first, InputIt last );
From [temp.deduct.call]:
When P is a function type, pointer to function type, or pointer to member function type:
— If the argument is an overload set containing one or more function templates, the parameter is treated
as a non-deduced context.
Since &std::set<int>::insert is precisely such an overload set, the parameter is a non-deduced context and cannot be resolved. Your example of MySet does not contain a function template overload for insert, which is why it works fine. If you add one, you'll see that it will also fail to compile.
This question is spawned from
Passing a member function pointer to an overloaded class method into a template function.
You need not read that to understand this question. Probably both the questions will have the same answer.
I am getting compiler error for below simple code.
#include<set>
template<typename Return, typename T>
T ReceiveFuncPtr (Return (T::*Method)(const int&))
{
T obj; // Found and declared an object of actual container class
(obj.*Method)(1); // Some processing
return obj; // Returned that container class object with RVO
}
int main ()
{
ReceiveFuncPtr(&std::set<int>::insert); // ERROR
}
The error is interesting:
In function 'int main()':
error: no matching function for call to 'ReceiveFuncPtr(<unresolved overloaded function type>)'
ReceiveFuncPtr(&std::set<int>::insert); // ERROR
^
note: candidate is:
note: template<class Return, class T> T ReceiveFuncPtr(Return (T::*)(const int&))
T ReceiveFuncPtr (Return (T::*Method)(const int&))
^
note: template argument deduction/substitution failed:
note: mismatched types 'const int&' and 'std::initializer_list<int>'
ReceiveFuncPtr(&std::set<int>::insert); // ERROR
^
note: mismatched types 'const int&' and 'std::set<int>::const_iterator {aka std::_Rb_tree_const_iterator<int>}'
note: mismatched types 'const int&' and 'std::set<int>::const_iterator {aka std::_Rb_tree_const_iterator<int>}'
note: mismatched types 'const int&' and 'std::set<int>::value_type&& {aka int&&}'
note: couldn't deduce template parameter 'Return'
If you look at the notes closely then it appears that compiler is matching all the other methods except the right one! In this case compiler should have matched insert(const std::set<int>::value_type&) aka const int&. If I change the ReceiveFuncPtr() to match some other overload, it will again fail by skipping that overload.
To debug this situation, I created handcrafted version of std::set. But that compiles fine:
template<typename T, typename T2 = void>
struct MySet
{
std::pair<T,bool> insert (const T& i) { return std::pair<T,bool>(T(),true); }
std::pair<T,bool> insert (T&& i) { return std::pair<T,bool>(T(),true); }
void insert (std::initializer_list<T> i) { return false; }
}
int main ()
{
ReceiveFuncPtr(&MySet<int>::insert); // OK
}
After surfing, I came across this post:
What are the rules for function pointers and member function pointers to Standard functions?
Though it's related , it doesn't solve problem.
Question: Why member function substitution fails in case of standard library method when the the same thing passes for handwritten class method?
Update:
After looking at the correct answer, I am sure that insert cannot be used. The only way would be ugly typecasting which is an overkill for this problem.
One elegant solution is to use std::set<int>::emplace<const int&> which has only templated version unlike insert which has mix of template and non-template versions.
Call the function as below:
ReceiveFuncPtr(&std::set<int>::emplace<const int&>);
Above compiles fine.
The problem isn't with the insert functions you showed in MySet. The problem is with one of the ones you omitted. Specifically:
template< class InputIt >
void insert( InputIt first, InputIt last );
From [temp.deduct.call]:
When P is a function type, pointer to function type, or pointer to member function type:
— If the argument is an overload set containing one or more function templates, the parameter is treated
as a non-deduced context.
Since &std::set<int>::insert is precisely such an overload set, the parameter is a non-deduced context and cannot be resolved. Your example of MySet does not contain a function template overload for insert, which is why it works fine. If you add one, you'll see that it will also fail to compile.
#include <array>
#include <vector>
#include <cinttypes>
#include <iostream>
using namespace std;
template<size_t N>
struct item_t {
array<uint32_t, N> weight = {0};
};
int main(void) {
vector<item_t<3>> items;
items.emplace_back({{9,2,3}});
cout << items[0].weight[0] << endl;
return 0;
};
I'm at a bit of a loss here. Error is on the emplace_back line and no idea how to resolve it. Any help or hints would be appreciated, thanks.
EDIT
gcc version 4.8.2
$ g++ -std=c++11 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:16:30: error: no matching function for call to ‘std::vector<item_t<3ul> >::emplace_back(<brace-enclosed initializer list>)’
items.emplace_back({{9,2,3}});
^
test.cpp:16:30: note: candidate is:
In file included from /usr/include/c++/4.8/vector:69:0,
from test.cpp:2:
/usr/include/c++/4.8/bits/vector.tcc:91:7: note: void std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {}; _Tp = item_t<3ul>; _Alloc = std::allocator<item_t<3ul> >]
vector<_Tp, _Alloc>::
^
/usr/include/c++/4.8/bits/vector.tcc:91:7: note: candidate expects 0 arguments, 1 provided
The problem is with the struct initialization = {0} and with emplace_back.
emplace_back() uses template argument deduction to determine the types of the elements passed to the function. A brace enclosed initializer list is not an expression and doesn't have type and therefore cannot be deduced by the template. You have to explicitly call the constructor here:
items.emplace_back(item_t<3>{{1,2,3}});
There are two issues here :
Trying to init a object of type T like this T{...} is referred to as aggregate initialization. Under some conditions, there is a default behaviour specified for it, even if you don't have a constructor which accepts a initializer_list. In C++11, you are not allowed to provide non-default constructors or in-class initializers. So, given this definition
template<size_t N>
struct item_t {
array<uint32_t, N> weight = {0};
};
you cannot write item_t<3> t{1,2,3};.
That, however, isn't your problem. The reason your code fails is that emplace_back tries to forward the arguments to a constructor of the vectors underlying type. In your case, there isn't a match. Note that nice a braced-init list isn't equivalent to an initializer_list in this context, you cannot solve this problem by adding an initializer_list constructor and will have to help the compiler out some other way.
Consider the following code:
#include<iostream>
#include<vector>
using namespace std;
class Foo {
public:
template< typename T>
operator vector< T >() const {
return vector< T >();
}
template< typename T>
operator T() const {
return T();
}
};
int main () {
Foo b;
vector< int > q = b;
q = b;
}
Compiling this with Clang or g++ using either of the two commands:
g++ test.cpp
clang++ test.cpp
Enabling C++11 features, however, it fails:
g++ --std=c++0x test.cpp
clang++ --std=c++11 test.cpp
The error message reads as follows:
test.cpp:20:5: error: use of overloaded operator '=' is ambiguous (with operand types 'vector<int>' and 'Foo')
q = b;
~ ^ ~
/usr/include/c++/4.6/bits/stl_vector.h:373:7: note: candidate function
operator=(vector&& __x)
^
/usr/include/c++/4.6/bits/stl_vector.h:362:7: note: candidate function
operator=(const vector& __x);
^
/usr/include/c++/4.6/bits/stl_vector.h:394:7: note: candidate function
operator=(initializer_list<value_type> __l)
^
1 error generated.
It is unclear to me why it works without C++11, while it fails with. Moveover, note that the line
vector< int > q = b; // In the main function, line 19
in the main function does not cause an error. Can anyone explain why it does not work, and what one can do to make it work with C++11?
There's no compiler bug here. Your code is broken in C++11, because C++11 added more converting constructors and more overloads for the assignment operator.
This is the risk you run when you make a type that converts to absolutely anything (using templated conversion). Foo is just as happy to convert itself to an initializer_list<int> as a vector<int>.
The reason that
vector<int> q = b;
works in Clang 3.1, while
vector<int> q(b);
fails, is that the first is copy-initialization, which requires an implicit conversion to vector<int> followed by a copy-constructor call, while the second is direct-initialization which performs an explicit conversion. The set of candidates for implicit conversion is smaller, because constructors marked explicit are removed, resolving the ambiguity.
The difference between Clang 3.0 and 3.1 is likely a library compliance fix, which marked additional constructors as explicit, not a change to compiler behavior.
Consider the following code to iterate over an intrusive list using the BOOST_FOREACH macro:
#include <boost/foreach.hpp>
#include <boost/intrusive/list.hpp>
typedef boost::intrusive::list<
boost::intrusive::list_base_hook<> > MyList;
void iterate (const MyList& xs) {
BOOST_FOREACH (MyList::const_reference node, xs);
}
int main () {
MyList xs;
iterate (xs);
return 0;
}
Given boost version 1.48 the code fails with clang 3.2 (SVN) and gcc 4.6.3, but works with gcc 4.5.3. With non-const-qualified parameter xs to iterate the code works. With C++11 enabled all of the compilers accept the code. When using boost-1.46 both gcc versions accept the code, but clang still doesn't.
Is the code at hand a misuse of the BOOST_FOREACH macro, or is the error at boosts side? Is there a workaround that is nicer than iteration with regular for-loop?
Edit:
I pasted the error messages to pastebin (both are very verbose) for GCC and clang.
Here is what I could gather from the logs as well as my deductions as to the cause of failure.
Short version: for some reason BOOST_FOREACH attempts to copy the data which is not possible.
There is a note on the Extensibility page:
Making BOOST_FOREACH Work with Non-Copyable Sequence Types
For sequence types that are non-copyable, we will need to tell BOOST_FOREACH to not try to make copies. If our type inherits from boost::noncopyable, no further action is required. If not, we must specialize the boost::foreach::is_noncopyable<> template [...] Another way to achieve the same effect is to override the global boost_foreach_is_noncopyable() function. Doing it this way has the advantage of being portable to older compilers.
From the diagnosis, it is unclear whether the type is properly configured, so you might want to give it a go.
Pruned diagnosis and analysis.
/usr/include/boost/foreach.hpp:571:37: error: no matching constructor for initialization of 'boost::intrusive::list< >'
::new(this->data.address()) T(t);
^ ~
/usr/include/boost/foreach.hpp:648:51: note: in instantiation of member function 'boost::foreach_detail_::simple_variant<boost::intrusive::list< > >::simple_variant' requested here
return auto_any<simple_variant<T> >(*rvalue ? simple_variant<T>(t) : simple_variant<T>(&t));
^
/usr/include/boost/intrusive/list.hpp:1490:35: note: candidate constructor not viable: 1st argument ('const boost::intrusive::list< >') would lose const qualifier
BOOST_MOVABLE_BUT_NOT_COPYABLE(list)
^
/usr/include/boost/move/move.hpp:371:7: note: expanded from macro 'BOOST_MOVABLE_BUT_NOT_COPYABLE'
TYPE(TYPE &);\
/usr/include/boost/intrusive/list.hpp:1497:4: note: candidate constructor not viable: no known conversion from 'const boost::intrusive::list< >' to 'const value_traits' (aka 'const boost::intrusive::detail::base_hook_traits<boost::intrusive::list_base_hook< >, boost::intrusive::list_node_traits<void *>, 1, boost::intrusive::default_tag, 1>') for 1st argument;
list(const value_traits &v_traits = value_traits())
^
/usr/include/boost/intrusive/list.hpp:1506:4: note: candidate constructor not viable: no known conversion from 'const boost::intrusive::list< >' to '::boost::rv<list< >> &' for 1st argument;
list(BOOST_RV_REF(list) x)
^
/usr/include/boost/intrusive/list.hpp:1502:4: note: candidate constructor template not viable: requires at least 2 arguments, but 1 was provided
list(Iterator b, Iterator e, const value_traits &v_traits = value_traits())
^
I tried to isolate the error as much as possible (removing backtraces etc..) Apparently the problem stems from boost::intrusive::list, and more precisely the inability to build a new boost::intrusive::list<> from a boost::intrusive::list<> const.
The most promising constructor is defined by a macro:
BOOST_MOVABLE_BUT_NOT_COPYABLE(list)
which expands to
list(list&);
which is the way boost emulates move semantics for non-copyable types in C++03. However it cannot move from a const item since the const qualifier would be lost.
This looks to be part of the trickery used by BOOST_FOREACH to avoid multiple evaluation of the container argument (in case it is a function invocation) though I am a little surprised it tries to copy the argument here.
Since you are using gcc > 4.6 and clang 3.2, you could use C++11's range-based for looops:
#include <boost/foreach.hpp>
#include <boost/intrusive/list.hpp>
typedef boost::intrusive::list<
boost::intrusive::list_base_hook<> > MyList;
void iterate (const MyList& xs) {
for(const auto &node : xs) {
// do something with node
}
}
int main () {
MyList xs;
iterate (xs);
return 0;
}
You could also use std::for_each:
void iterate (const MyList& xs) {
std::for_each(xs.begin(), xs.end(),
[](MyList::const_reference node) {
// do something with node
}
);
}