template-meta-programming

I have the following problem. Say you want to write a generic function that can take a lambda expression. I understand that if the parameter is of type std::function, then I could not only use lambdas, but also functions and even pointers to functions. So at a first step, I did the following: void print(std::function<void(int, int)> fn) { fn(1,2); } int main() { print([](int i, int j) { std::cout << j <<','<<i<<'\n'; }); return 0; } Now the problem is that I want to make this function generic, meaning that I don't want the lambda expression to have only two parameters. So I tried changing the

I would like to wrap member functions that conform to the type 'void (ClassType::Function)(ArgType)' with a templated class. Later, I want to pass an instance of ClassType to an instance of this template and have it invoke the wrapped method: class Foo { public: Foo() : f_(0.0) {} void set(double v) { f_ = v * 2.1; } double get() { return f_; } private: double f_; }; template <typename ArgType, typename ClassType, void (ClassType::*Method)(ArgType)> class Wrapper { public: explicit Wrapper(ClassType *cls) : cls_(cls) {} void do_something(ArgType value) { (cls_->*Method)(value); } private:

Currently, only doubles can produce a template of chars in a user defined literal: template <char...> double operator "" _x(); // Later 1.3_x; // OK "1.3"_y; // C++14 does not allow a _y user- // defined operator to parse that as a template of chars Is there a clever way to produce a std::integer_sequence of chars using a user defined literal. In other words, what the code of _y(const char*, std::size_t) would be so that I end up with a std::integer_sequence<char, '1', '.', '3'> ? At this point in time, the best we can (portably) do is a macro trick as demonstrated for vtmpl::string .

template<typename T> struct check { static const bool value = false; }; What I want to do is to have check<T>::value be true if and only if T is a std::map<A,B> or std::unordered_map<A,B> and both A and B be std::string . So basically check enables compile-time checking of the type T . How do I do this? Xeo Partial specialization for when you want to allow any comparator, hasher, key-equal-comparator and allocator: template<class Comp, class Alloc> struct check<std::map<std::string, std::string, Comp, Alloc>>{ static const bool value = true; }; template<class Hash, class KeyEq, class Alloc>

I am experimenting with the new features of C++11. In my setup I would really love to use inheriting constructors, but unfortunately no compiler implements those yet. Therefore I am trying to simulate the same behaviour. I can write something like this: template <class T> class Wrapper : public T { public: template <typename... As> Wrapper(As && ... as) : T { std::forward<As>(as)... } { } // ... nice additions to T ... }; This works... most of the time. Sometimes the code using the Wrapper class(es) must use SFINAE to detect how such a Wrapper<T> can be constructed. There is however the

This question already has an answer here: Fallback variadic constructor - why does this work? 1 answer Consider this program: #include <iostream> #include <type_traits> using namespace std; struct russell { template <typename barber, typename = typename enable_if<!is_convertible<barber, russell>::value>::type> russell(barber) {} }; russell verify1() { return 42L; } russell verify2() { return 42; } int main () { verify1(); verify2(); cout << is_convertible<long, russell>::value; cout << is_convertible<int, russell>::value; return 0; } If some type barber is not convertible to russell . we

This is a follow-up of another question . It refers to the same problem (I hope) but uses an entirely different example to illustrate it. The reason is that in the previous example only experimental GCC 4.9 failed with a compiler error. In this example, also Clang and GCC 4.8.1 fail in different ways: Clang produces an unexpected result and GCC 4.8.1 reports a different error message. Answers to the previous question say more or less that the code is valid and the problem lies with the experimental version of GCC. But this result makes me a bit more sceptical. I have been troubled for months