I'm experimenting with C++11 (I've used old C++ so far) and I wrote the following code:
#include <iostream>
#include <vector>
#include <type_traits>
using namespace std;
constexpr bool all_true(){
return true;
}
template <typename Head, typename... Tail>
constexpr bool all_true(Head head, Tail... tail){
static_assert( is_convertible<bool, Head>::value, "all_true arguments must be convertible to bool!");
return static_cast<bool>(head) && all_true(tail...);
}
template<typename T, typename... Args>
void print_as(Args... args){
static_assert( all_true(is_convertible<T,Args>::value...), "all arguments must be convertible to the specified type!");
vector<T> v {static_cast<T>(args)...};
for(T i : v) cout << i << endl;
}
int main(){
print_as<bool>(1, 2, 0, 4.1);
}
The code compiles and runs as expected (I used gcc 4.6). I would like to aks the following questions:
I initialized a std::vector with an expanded parameter pack ( vector v {static_cast(args)...}; ). Is this correct C++11? I haven't found this feature explained anywhere.
I don't like too much the declaration of all_true because I know the type but I use templates. Is it possible to use something similar to the following?
constexpr bool all_true(bool head, bool... tail){...} // This code doesn't compile
Thanks!
Yes, it is possible to use pack expansions inside initialiser lists. C++11 [temp.variadic]§4 allows this:
... Pack expansions can occur in the following contexts:
...
In an initializer-list (8.5); the pattern is an initializer-clause.
No, there's no way to make a non-template typesafe variadic function. What you have is OK. There was a question about this recently.
Related
I learned that from C++17, with the deduction guides, template arguments of std::vector can be deduced e.g. from the initialization:
std::vector vec = { function_that_calculate_and_return_a_specifically_templated_type() }
However I do not have the luxury of C++17 in the machine where I want to compile and run the code now.
Is there any possible workaround for C++11? If more solutions exist, the best would be the one that keep the readability of the code.
At the moment the only idea that I have is to track the various cases along the code (luckily they should not be too many) and make some explicit typedef/using.
Any suggestion is very welcome
The usual way to use type deduction for class template when CTAD is not available is providing a make_* function template, e.g. for your case (trailing return type is necessary for C++11):
#include <vector>
#include <type_traits>
#include <tuple>
template <class ...Args>
auto make_vec(Args&&... args) ->
std::vector<typename std::decay<typename std::tuple_element<0, std::tuple<Args...>>::type>::type>
{
using First = typename std::decay<typename std::tuple_element<0, std::tuple<Args...>>::type>::type;
return std::vector<First>{std::forward<Args>(args)...};
}
You can invoke the above with
const auto v = make_vec(1, 2, 3);
which gets at least kind of close to CTAD in the sense that you don't have to explicitly specify the vector instantiation.
While the answer by lubgr is a correct way, the following template is simpler and seems to work as well:
#include <vector>
#include <string>
template <typename T>
std::vector<T> make_vec(const std::initializer_list<T> &list)
{
return std::vector<T>(list);
}
int main()
{
auto v = make_vec({1,2,3});
auto v2 = make_vec({std::string("s")});
std::string s("t");
auto v3 = make_vec({s});
return v.size() + v2.size() + v3.size();
}
One advantage of using the initializer_list template directly are more clear error messages if you pass mixed types like in make_vec({1,2,"x"});, because the construction of the invalid initializer list now happens in non-templated code.
This looks like an issue in clang (I've already opened a bug here), but I'd like to be sure that I'm not doing a mistake.
Consider the following code:
#include <type_traits>
#include <cstddef>
template<std::size_t N, std::size_t M, std::enable_if_t<not (N>M)>* = nullptr> // (1)
struct S: public S<N+1, M> { };
template<std::size_t N>
struct S<N, N> { };
int main() {
S<0, 1> c{};
}
It fails to compile with the following error:
8 : error: non-type template argument specializes a template parameter with dependent type 'std::enable_if_t M)> *' (aka 'typename enable_if M), void>::type *')
struct S { };
The same code works as expected using the following line instead of (1):
template<std::size_t N, std::size_t M, typename = std::enable_if_t<not (N>M)>>
The SFINAE expression is almost the same. It is based on a specialization of std::enable_if_t and I would expect the same result (success or failure) for both of the examples.
Are my expectations wrong?
Note that GCC works fine in either cases.
I think this is a gcc bug actually, as a result of [temp.class.spec]:
The type of a template parameter corresponding to a specialized
non-type argument shall not be dependent on a parameter of the
specialization. [ Example:
template <class T, T t> struct C {};
template <class T> struct C<T, 1>; // error
template< int X, int (*array_ptr)[X] > class A {};
int array[5];
template< int X > class A<X,&array> { }; // error
—end example ]
In your example, the type of the 3rd template parameter is dependent on a parameter. When you swap it to typename = std::enable_if_t<...>, then this rule no longer applies.
Note: is there any reason to use SFINAE here anyway, as opposed to static_assert-ing?
I have a std::tuple (or a boost fusion tuple) whose elements cannot be trivially constructed (for example references) and I want to iterate over the types but not the values of the elements.
In this example I have a (general) tuple type and I want to generate a vector with (runtime) type information. The example below works if all the types in the sequence are trivially default constructed but not in general.
In summary, I want a function that transform: std::tuple<...> -> std::vector<std::type_index>
#include <boost/fusion/adapted/std_tuple.hpp>
#include <boost/fusion/algorithm/iteration/for_each.hpp>
#include <typeindex>
#include<vector>
using tuple_type = std::tuple<std::string&, int>;
int main(){
std::vector<std::type_index> types;
boost::fusion::for_each(
tuple_type{}, // fails because of std::string&
[&types](auto& e){types.push_back(typeid(e));}
);
}
The problem is that I have to generate runtime information from non runtime information and I can't figure out how to mix the fusion functions (http://www.boost.org/doc/libs/1_59_0/libs/fusion/doc/html/fusion/algorithm/iteration/functions.html) and the metafunctions (http://www.boost.org/doc/libs/1_41_0/libs/fusion/doc/html/fusion/algorithm/iteration/metafunctions.html).
I tried with boost::fusion::accumulate and boost::fold but the situation is always the same, at some point I have to generate a runtime element in order to apply the algorithm.
EDIT: I solved the original problem (std::tuple<...> -> std::vector<std::type_index>). I can't imagine another context at the moment but maybe the fundamental question still stands.
I did it by using a trick involving expanding a parameter pack over the typeid function in the constructor of std::vector (or std::array).
template<class... Args>
std::array<std::type_index, sizeof...(Args)> const& types_info<std::tuple<Args...>>::value{typeid(Args)...};
The complete code is this (note that I also decided to use std::array).
#include <typeindex>
#include<array>
#include<iostream>
template<class T>
struct types_info;
template<class... Args>
struct types_info<std::tuple<Args...>>{
static std::array<std::type_index, sizeof...(Args)> const& value;//{typeid(Args)...};
};
template<class... Args>
std::array<std::type_index, sizeof...(Args)> const& types_info<std::tuple<Args...>>::value{typeid(Args)...};
// vvv works only in C++1z
template<template<typename...> typename T, class... Args> // non tuples types as well
struct types_info<T<Args...>> : types_info<std::tuple<Args...>>{};
using tuple_type = std::tuple<std::string&, int>;
int main(){
std::vector<std::type_index> types;
std::cout << types_info<tuple_type>::value.size() << std::endl;
std::cout << types_info<std::map<int, std::string>>::value.size() << std::endl;
}
There are several proposals on how to print a tuple. The snippet below reproduces the answer of Kenny from overloading operator << for std::tuple - possible simplications?.
#include <iostream>
#include <tuple>
#include <type_traits>
// template <typename... T>
// std::ostream& operator<<(std::ostream& os, const std::tuple<T...>& tup);
template <size_t n, typename... T>
typename std::enable_if<(n >= sizeof...(T))>::type
print_tuple(std::ostream&, const std::tuple<T...>&)
{}
template <size_t n, typename... T>
typename std::enable_if<(n < sizeof...(T))>::type
print_tuple(std::ostream& os, const std::tuple<T...>& tup)
{
if (n != 0)
os << ", ";
os << std::get<n>(tup);
print_tuple<n+1>(os, tup);
}
template <typename... T>
std::ostream& operator<<(std::ostream& os, const std::tuple<T...>& tup)
{
os << "[";
print_tuple<0>(os, tup);
return os << "]";
}
int
main()
{
auto t = std::make_tuple(1, std::make_tuple(2, 3));
std::cout << t << std::endl;
}
My problem is that it does not work properly with clang (3.5) with tuples of tuples (gcc 4.9 is happy though):
clang++-mp-3.5 -std=c++11 print.cc
print.cc:19:10: error: call to function 'operator<<' that is neither visible in the
template definition nor found by argument-dependent lookup
os << std::get<n>(tup);
^
print.cc:20:7: note: in instantiation of function template specialization
'print_tuple<1, int, std::__1::tuple<int, int> >' requested here
print_tuple<n+1>(os, tup);
^
print.cc:27:7: note: in instantiation of function template specialization
'print_tuple<0, int, std::__1::tuple<int, int> >' requested here
print_tuple<0>(os, tup);
^
print.cc:35:19: note: in instantiation of function template specialization
'operator<<<int, std::__1::tuple<int, int> >' requested here
std::cout << t << std::endl;
^
print.cc:24:19: note: 'operator<<' should be declared prior to the call site
std::ostream& operator<<(std::ostream& os, const std::tuple<T...>& tup)
^
If I uncomment the forward declaration for operator<< on tuples, it works. However it does not fit nicely in a framework where you don't force the definition of operator<< for tuples, but leave to the user the choice to bind it to print_tuple: she has to forward declare the function before including the header that defines print_tuple.
I don't understand well what's going on here: in a template, clang appears to refuse to use functions that are defined after the point of the definition of the template, but before the point of instantiation. I would have thought that what matters is the point of instantiation.
Conversely, why does GCC accept? Is one of the compilers wrong? What would be the nicest way to leave to the user the choice of defining this operator<<, and have it work properly recursively?
Thanks.
You can read about the reason clang is not compiling it here: http://clang.llvm.org/compatibility.html#dep_lookup . It seems that clang's behaviour is standard-compliant.
To fix it, you can define operator<< in namespace std to make argument-dependent lookup work correctly. Actually this might be undefined behaviour, since it does not comply with the requirements for adding stuff to std.
I've got quite a simple function using static_assert. The trouble is that I want to static_assert on behaviour involved in the function declaration- inferring the return type, specifically. There don't seem to be any places to interject the static_assert so that I can fire it before the compiler fails to deduce the return type.
So far, I put return type deduction and the static assertion in a struct. This will fire the assertion, which is great, but it'll still generate an error on the type deduction, which is noise I want to eliminate.
#include <type_traits>
#include <functional>
#include <memory>
#include <map>
#include <iostream>
#include <string>
#include <cstdio>
#include <tuple>
#include <sstream>
#include <vector>
#include <algorithm>
template<typename T, typename X> struct is_addable {
template<typename Test, typename Test2> static char test(decltype(*static_cast<Test*>(nullptr) + *static_cast<Test2*>(nullptr))*);
template<typename Test, typename Test2> static int test(...);
static const bool value = std::is_same<char, decltype(test<T, X>(nullptr))>::value;
};
template<typename T, typename X> struct is_addable_fail {
static const bool value = is_addable<T, X>::value;
static_assert(value, "Must be addable!");
typedef decltype(*static_cast<T*>(nullptr) + *static_cast<X*>(nullptr)) lvalue_type;
};
template<typename T1, typename T2> auto Add(T1&& t1, T2&& t2) -> typename is_addable_fail<T1, T2>::lvalue_type {
return std::forward<T1>(t1) + std::forward<T2>(t2);
}
struct f {};
int main() {
std::cout << Add(std::string("Hello"), std::string(" world!"));
Add(f(), f());
}
It's not possible because of the way candidate sets are built and SFINAE. If you could assert before a function's signature has fully been determined then that would require you to assert before it has been decided that the function is the one that is going to be used.
The order of steps is essentially:
Find matching functions
Substitute deduced parameters into the function arguments and return type.
Discard those that fail (SFINAE)
If one left, use that.
When do you want the assert to fire?
If you fire it during parameter substitution then you are ruling out SFINAE, and if you fire it any time after that then the return type has already been determined (too late).
Though I may misunderstand the question,
does SFINAE like the following meet the purpose?
template<typename T = int> void Add(...) {
static_assert(sizeof(T) == 0, "Must be addable!");
}
template<typename T1, typename T2> auto Add(T1&& t1, T2&& t2) ->
decltype(std::forward<T1>(t1) + std::forward<T2>(t2)) {
return std::forward<T1>(t1) + std::forward<T2>(t2);
}
Here is a test on ideone.
The shortcoming is that Add has to be repeated.
EDIT:
Though I'm not totally sure this is strictly standard conforming, does the
following work-around help?
(a test on ideone)
template<typename T1, typename T2> void Add(T1 volatile&&, T2 volatile&&) {
static_assert(sizeof(T1) == 0, "Must be addable!");
}