I went to see if you could use auto in a variable template declaration.
template <typename T>
auto F = T{};
Fine, but as soon as you try to use it, clang craps.
int f = F<int>; // error: cannot initialize a variable of type 'int' with an lvalue of type 'auto'
auto f = F<int>; // Stacktrace
decltype(F<int>) f = F<int>; // StackFace
std::cout << std::is_same<int, decltype(F<int>)>::value; // false
std::cout << typeid(decltype(F<int>)).name(); // Stacktrace
std::cout << std::is_same<decltype(F<int>), decltype(F<int>)>::value; // true
Any combination of decltype(auto), auto doesn't work even though it says that auto is an lvalue.
int f = static_cast<int>(F<int>); // error: static_cast from 'auto' to 'int' is not allowed
I've never seen auto act this way before. Is it because of variable templates or because of how clang treats auto?
This seems to be addressed in the latest version of clang; putting that into a file and calling
clang++ -std=c++1y test.cpp
gives me no errors.
kevinushey#Kevin-MBP:~$ clang++ -v
clang version 3.5 (trunk 201469)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Related
So, I am trying to implement the dot product (https://en.wikipedia.org/wiki/Dot_product) in some flavour of modern C++ and came up with the following code:
#include <iostream>
template<class... Args>
auto dot(Args... args)
{
auto a = [args...](Args...)
{
return [=](auto... brgs)
{
static_assert(sizeof...(args) == sizeof...(brgs));
auto v1 = {args...}, i1 = v1.begin();
auto v2 = {brgs...}, i2 = v2.begin();
typename std::common_type<Args...>::type s = 0;
while( i1 != v1.end() && i2!= v2.end())
{
s += *i1++ * *i2++;
}
return s;
};
};
return a(std::forward<Args>(args)...);
}
int main()
{
auto a = dot(1,3,-5)(4,-2,-1);
std::cout << a << std::endl;
}
Online: https://gcc.godbolt.org/z/kDSney and also: cppinsights
The code above compiles and executes nicely with g++, however clang (and icc and msvc) choke on it:
clang++ ./funcpp.cpp --std=c++17
./funcpp.cpp:12:4: error: 'auto' deduced as 'std::initializer_list<int>' in declaration of
'v1' and deduced as 'const int *' in declaration of 'i1'
auto v1 = {args...}, i1 = v1.begin();
^ ~~~~~~~~~ ~~~~~~~~~~
./funcpp.cpp:28:11: note: in instantiation of function template specialization
'dot<int, int, int>' requested here
auto a = dot(1,3,-5)(4,-2,-1);
^
1 error generated.
Now, if I break up the definition of v1, v2, i1, i2 like:
auto v1 = {args...} ;
auto i1 = v1.begin();
auto v2 = {brgs...};
auto i2 = v2.begin();
clang and msvc have no problems, icc still chokes:
<source>(10): error: static assertion failed
static_assert(sizeof...(args) == sizeof...(brgs));
^
detected during instantiation of "auto dot(Args...) [with Args=<int, int, int>]" at line 30
compilation aborted for <source> (code 2)
Execution build compiler returned: 2
However if I remove the offending static_assert then icc has no issues compiling the code either.
And beside of the (typical) question: which is right and why :) the concrete question is:
According to [dcl.spec.auto] :
if the type that replaces the placeholder type is not the same in each deduction, the program is ill-formed
clang correctly identified that there are two different types defined in the line in question: 'auto' deduced as 'std::initializer_list<int>' in declaration of 'v1' and deduced as 'const int *' in declaration of 'i1' so I'd like to hear your opinions whether:
did I hit some undocumented g++ extension considering this specific situation (not mentioned in https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C_002b_002b-Extensions.html#C_002b_002b-Extensions) since g++ to my knowledge correctly handles the different types in an auto declaration list,
or by any chance g++ did not deduce the two types to be different (... hm...)
or something else?
Thanks for reading through this long question.
(As a bonus if someone could answer why icc fails on the static_assert would be great.)
Expanding from my comments:
g++ does not do this always, consider the example auto i = 0l, f = 0.0;, it gives the error:
test.cpp: In function ‘int main()’:
test.cpp:4:5: error: inconsistent deduction for ‘auto’: ‘long int’ and then ‘double’
4 | auto i = 0l, f = 0.0;
If we compile your program and print the types of the variables (with this method), we get the following output:
v1: std::initializer_list<int>, i1: int const*
v2: std::initializer_list<int>, i2: int const*
using gcc version 9.2.0, with flags -std=c++17 -pedantic -Wall -Wextra without any warning or error.
By your comment of the standard this program is ill-formed and the standard specifies that there should be emitted a diagnostic message (warning or error) unless otherwise specified (which it is not, in this case). Hence I would say that this is a bug in gcc.
It is a known bug.
The static_assert fail on ICC is definitely a bug. I found a simple workaround by moving static_assert into a separate function. Not very elegant solution, but it works.
With slight modifications, this is the code that compiles with GCC, Clang and ICC:
template<std::size_t size, class... Args>
void args_no_guard(Args... args)
{
static_assert(sizeof...(args) == size);
}
template<class... Args>
auto dot(Args... args)
{
return [=](auto... brgs)
{
constexpr auto n = sizeof...(args);
args_no_guard<n>(brgs...);
using T = std::common_type_t<decltype(args)..., decltype(brgs)...>;
const T v1[]{static_cast<T>(args)...};
const T v2[]{static_cast<T>(brgs)...};
T dot = 0;
for (std::size_t i = 0; i < n; ++i)
dot += v1[i] * v2[i];
return dot;
};
}
In trying to understand c++17 compliant code, i am confused by the following code in
which the function uses the value from integral_constant type argument in the
trailing return type. (please feel free to correct my terminolgy etc, trying to learn)
Two simple versions are illustrated below , with and without a decltype on the
argument in the trailing return.
Using Compiler Explorer https://godbolt.org/z/vqmzhu
The first (bool_from1) compiles ok on
MSVC 15.8; /std:c++17, /O2, /permissive-
and clang 8.7.0.0 and gcc 8.2; -std=c++17, -O2, -pedantic
with correct assembler output
The second (bool_from2) errors out on gcc,
It also shows Intellisense errors in VS but compiles without error.
I could not find anything in cppreference or standard draft, etc that would indicate to me that the decltype(atype) would be required for conforming code, however...???
My question would be is the decltype required.
Are my compiler flags correct for c++17 conformance checking.
CODE:
#include <utility>
namespace ns {
volatile bool vb;
template<bool B> struct bool_ : std::bool_constant<B> {};
// using decltype(btype) in trailing return compiles in all 3
template<typename Bool> constexpr auto bool_from1(Bool btype)
-> bool_<decltype(btype)::value> {
return bool_<btype.value>{};
}
void test1() {
static_assert( // simple test
bool_from1(std::true_type{}).value
);
vb = bool_from1(std::true_type{}).value; // check output
}
// without decltype in trailing return compile in VS and clang
// but errors out in gcc; and VS shows Intelisense errors but compiles
template<typename Bool>
constexpr auto bool_from2(Bool btype)
// ^ gcc 8.2 error: deduced class type 'bool_' in function return type
-> bool_<btype.value> {
// ^ gcc: invalid template-id; use of paramter outside function body before '.'
//^ VS Intellisense on btype: <error-constant>; a paramter is not allowed
return bool_<btype.value>{};
}
void test2() {
static_assert(
bool_from2(std::true_type{}).value
//^ gcc: bool_from1 was not declared in this scope
);
vb = bool_from2(std::true_type{}).value; // check output
}
}
This looks like a gcc bug and bug report: "Trailing return types" with "non-type template arguments" which could be "constant expressions" produce a parsing error seems to fit this case:
Consider the following snippet:
template <int>
struct bar {};
template <class I>
auto foo(I i) -> bar<i()> { return {}; }
int main()
{
foo([]{ return 1; }); // (0)
}
This compiles and works as intended on clang++5, but produces a
compile-time error on g++7:
prog.cc:5:25: error: template argument 1 is invalid
auto foo(I i) -> bar<i()> { return {}; }
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.
#include <iostream>
struct Index {
constexpr operator int() const { return 666; }
};
template <int i> void foo() {
std::cout << i << std::endl;
}
void wrapper(Index index) {
foo<index>();
}
int main() {
Index index;
// foo<index>(); // error: the value of ‘index’ is not usable in a constant expression
wrapper(index);
}
Hello, everyone.
I'm using a constexpr conversion of a variable "index" to an int value, which is substituted to a "foo" templated function.
If I directly call foo<index>() from "main", I get a compiler error.
If the same call is done from the "wrapper", then everything compiles and works fine.
What am I missing there?
Compile command: g++ -std=c++14 main.tex with g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6).
A very similar error was reported here. It was first reported with GCC 4.9.0
In the analysis provided:
This is a GCC bug. It appears to be some sort of confusion in the way GCC handles internal linkage non-type template parameters of pointer type.
It has since been resolved.
I have a MVE program that compiles and runs with g++-5.2.0 but not with clang-602.0.53. The program tries to assign a lambda expression to a type alias of compatible type.
#include<iostream>
#include<complex>
using std::cout;
using std::endl;
using std::complex;
// type alias
using CfDD = complex<double> (*) (double);
// lambda of compatible type
auto theLambda = [] (double _) {return complex<double>({1,0});};
int main()
{ // Show that the lambda is callable:
cout << theLambda(3.14) << endl;
// Show that the lambda is assignable to a var of type CfDD
CfDD cfdd = theLambda;
cout << cfdd (3.14) << endl;
}
This program works when compiled with g++-5.2.0:
$ g++-5 --version
g++-5 (Homebrew gcc 5.2.0) 5.2.0
...
$ g++-5 -std=c++14 main.cpp && ./a.out
(1,0)
(1,0)
But produces an error that I don't understand and don't know how to fix under clang:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with- gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
...
$ gcc -std=c++14 main.cpp
main.cpp:10:40: error: ambiguous conversion for functional-style cast from 'void' to
'complex<double>'
auto theLambda = [] (double _) {return complex<double>({1,0});};
^~~~~~~~~~~~~~~~~~~~~
... candidate is the implicit move constructor
class _LIBCPP_TYPE_VIS_ONLY complex<double>
^
... candidate is the implicit copy constructor
candidate constructor
complex<double>::complex(const complex<float>& __c)
What does this error mean and why doesn't this code compile?
When you wrote:
return complex<double>({1,0});
we look at the valid constructors for std::complex<double> and find:
constexpr complex(double re = 0.0, double im = 0.0); // (1)
constexpr complex( const complex& other ); // (2)
constexpr complex(const complex<float>& other); // (3a)
explicit constexpr complex(const complex<long double>& other); // (3b)
We're constructing this object with an initializer list. So (1) isn't viable, and neither is (3b) since that constructor is marked explicit. The other two, however, are both viable since both complex<double> and complex<float> can be constructed from two ints. Neither is better than the other, which is why clang complains about "ambiguous conversion".
The easiest solution is to drop the unnecessary {}s:
return complex<double>(1,0);
Note that you don't need to name the argument _, you can just not provide a name for it.