When I try to compile this:
#include <functional>
void f(std::function<void()> f)
{
}
void g()
{
f([](auto&&...){});
}
on gcc 7.3, I get the following error:
[x86-64 gcc 7.3 #1] error: could not convert '<lambda closure object>g()::<lambda(auto:1&&, ...)>{}' from 'g()::<lambda(auto:1&&, ...)>' to 'std::function<void()>'
Can someone explain why this is invalid c++? Or should I submit a bug report? (MSVC 14 accepts and compiles it to what I expect.)
This is a gcc bug. It interprets your lambda as follow:
[](auto&&, ...){}
So there's one argument, followed by C variadic.
If you add a name to your parameter pack, then it works as intended:
[](auto&&... pack){}
Related
Template argument deduction appears to be broken in Clang 6 for temporary objects.
g++ 8.1.0 compiles and runs the example correctly.
Clang 6.0.0 and 6.0.2 both error at the indicated line with this message:
error: expected unqualified-id
Print{1,"foo"s,2}; /********** Broken in Clang **********/
All Other lines work correctly.
The behavior is the same in both cases whether -std=c++17 or -std=c++2a is used.
The Clang c++ Status Page indicates that template argument deduction was implemented as of Clang 5 (P0091R3, P0512R0).
Is this a bug? Are there workarounds (e.g. compiler flags, not code changes)?
example:
template<class ...Ts>
void print(Ts...ts){ (( cout << ... << ts )); }
template<class ...Ts>
struct Print {
Print(Ts...ts){ (( cout << ... << ts )); }
};
int main(){
Print{1,"foo"s,2}; /********** Broken in Clang **********/
Print<int,string,int>{1,"foo"s,2};
auto p1 = Print{1,"foo"s,2};
Print p2{1,"foo"s,2};
print(1,"foo"s,2);
}
This is Clang bug 34091.
Luckily, it is already fixed, and the trunk build of Clang compiles this without issue.
As far as I know, however, there is currently no way to work around this without code changes, short of upgrading to the next Clang release whenever that comes out.
Consider the following code, which uses a function with variable arguments:
#include <iostream>
// Typedef function type
template<typename... Output>
using Func = void(Output*...);
// Function runner
template<typename... Output>
void run_func(Func<Output...>& func, Output*... output) {
for (int i=0 ; i < 10 ; ++i) {
func(output...);
}
}
void f(double* d) {
*d *= 2;
};
int main() {
double value = 1.0;
run_func(f, &value);
printf("%f\n", value);
}
Compiling this with g++ 4.7.3 works fine, and running produces 1024.0 as expected.
Compiling using icpc 14.0.2 crashes it...
templ.cc(21): internal error: assertion failed: lower_expr: bad kind (shared/cfe/edgcpfe/lower_il.c, line 18582)
run_func(f, &value);
^
Compiling with clang 3.5.0-1 gives the following error message:
templ.cc:21:3: error: no matching function for call to 'run_func'
run_func(f, &value);
^~~~~~~~
templ.cc:9:6: note: candidate template ignored: deduced conflicting types for parameter 'Output' ('double' vs. <double>)
void run_func(Func<Output...>& func, Output*... output) {
^
Is this a bug, or should have g++ not compiled this?
Why is clang deducing these "conflicting" types of double and <double>, is <double> meant to represent an unpacked arglist for example?
Update icpc 14.0.3 does not crash, and the program compiles and runs correctly.
See DPD200244439 at Intel® Composer XE 2013 SP1 Compilers Fixes List
Following the above discussion, it seems that this is indeed a bug in clang.
As pointed out by gha.st, skipping template using and using the native function type directly works:
void run_func(void (&func)(Output*...), Output*... output) {
I have a filed a bug against this here.
gcc's treatment of variadic templates is well known to be patchy (see for example this and this), but I wonder whether the following bug is already known (I cannot find it at bugzilla) or whether it is indeed a bug. Essentially, gcc (4.8.1) fails to expand a parameter pack inside a lambda:
#include <vector>
#include <algorithm>
#include <type_traits>
template<typename T, typename F, typename... X>
void bar(std::vector<T> const&c, F const&f, X&&... x)
{
std:for_each(c.begin(),c.end(),[&](const T&t)
{ f(t,std::forward<X>(x)...); });
}
this causes (even without any instantiation)
error: parameter packs not expanded with ‘...’:
{ f(t,std::forward<X>(x)...); });
^
any idea how to avoid that? (note: okay with icpc 14.0.2 and clang 3.4) Or is gcc correct after all and clang & icpc wrong?
edit Note that the problem is the lambda, as also this doesn't compile:
template<typename T, typename F, typename... X>
void bar(std::vector<T> const&c, F const&f, X&&... x)
{
auto func = [&](const T&t){ f(t,std::forward<X>(x)...); };
std:for_each(c.begin(),c.end(),func);
}
with the "error" report in the lambda defiition.
Given that the code compiles cleanly with both clang version 3.5 (trunk 202594) and more importantly with gcc version 4.9.0 20140302 (experimental) (GCC), both with -Wall, I would say it was an issue with the earlier versions of gcc.
I am looking for a gcc bugreport at http://gcc.gnu.org/bugzilla/ to confirm this.
NOTE: this question was caused by a bug in clang
In attemping to write a function taking an arbitrary number of intitializer_lists whose types need not match, I've stumbled upon a strange error:
template <typename... Ts>
void function(std::initializer_list<Ts> && ...args){
}
int main() {
function({1,2,3}, {'h', 'w'}, {"hello", "aloha"});
return 0;
}
The string literals cause a problem under clang but not under gcc with -pedantic -Wall -Wextra not warning about any extensions.
clang produces the error:
error: no matching function for call to 'function'
function({1,2,3}, {'h', 'w'}, {"hello", "aloha"});
^~~~~~~~
note: candidate function [with Ts = <int, char, char const[6]>] not
viable: no known conversion from 'const char [6]' to 'char const[6]' for
3rd argument
void function(std::initializer_list<Ts> && ...args){
^
So a few questions:
Is clang wrong for rejecting this or is gcc using an extension to deduce an initializer_list of arrays? Or is it deeper where gcc is just passing bad code?
Is this is the equivalent of passing an initializer_list of initializer_lists which is of course not allowed?
What is the difference between const char[6] and char const[6]?
Details:
clang version 3.4 (http://llvm.org/git/clang.git 9a65f4251fe5548e0b4478d584796ca84a6f5ebc) (http://llvm.org/git/llvm.git 4f67afc3d67d9a68f1b37767c9c2966a775186bd)
Target: x86_64-unknown-linux-gnu
Thread model: posix
gcc (Debian 4.7.2-5) 4.7.2
Debian 7
This is a bug in clang: it fails to perform the required array-to-pointer decay when deducing {"hello", "aloha"} against std::initializer_list<Ts>, but only when Ts is a parameter pack.
This program compiles fine:
#include <initializer_list>
template <typename T>
void function(std::initializer_list<T> il) {
}
int main() {
function({"hello", "aloha", "foobarbaz"});
}
but this program triggers the bug:
#include <initializer_list>
template <typename... T>
void function(std::initializer_list<T>... il) {
}
int main() {
function({"hello", "aloha", "foobarbaz"});
}
Edit: Could not find this bug in the LLVM bugzilla tracker, submitted as bug# 18047.
I have such code:
#include <functional>
struct Foo {
template<typename T>
static void f(int);
};
template<>
void Foo::f<int>(int) {}
int main()
{
std::function<void(int)> func;
//func = static_cast<void (*)(int)>(Foo::f<int>);/works
func = Foo::f<int>;//compilation failure
return 0;
}
VS 2012 and 2013 Preview give compile time error at line:
func = Foo::f<int>;//compilation failure
error C3867: Foo::f: in function call no argument list, use "&Foo::f" to create pointer to member
error C2440: =: can not convert "overloaded-function" into "std::function"
But gcc 4.8.1, clang 3.3 and Intel Compiler 13.1.3 compile
this code with options (-Wall -pedantic -std=c++11) without
any warnings and errors.
So is this compiler bug of C++ compiler of Visual Studio?
Yes, it is a bug, visual studio 2013 rc compiles this without a problem so it looks like they have fixed it.