I would like to implement a specialized invoke with extra conversion on the arguments using C++11/14. Basically, the idea is:
struct Foo {
private:
void* ptr;
public:
void* get();
};
template <typename F, typename... Args>
auto convert_invoke(F&& f, Args&&... args) {
// not sure how to do here with C++11/14
}
// caller side
int simple(float* f1, size_t N) {
// doing something interesting
}
// ideally I would like to call the following:
Foo foo;
size_t n = 10;
convert_invoke(simple, foo, n); // internally calls simple((float*)foo.get(), n);
The idea here is when the argument is of type Foo, I will do some specialized processing like getting the void* pointer and cast it to the corresponding argument type defined in simple. How can I implement this in convert_invoke?
You might do something like:
// Wrapper to allow conversion to expected pointer.
struct FooWrapper
{
void* p;
// Allow conversion to any pointer type
template <typename T>
operator T* () { return (T*) p; }
};
// Identity function by default
template <typename T>
decltype(auto) convert(T&& t) // C++14
// auto convert(T&& t) -> decltype(std::forward<T>(t)) // C++11
{ return std::forward<T>(t); }
// special case for Foo, probably need other overloads for Foo&& and cv versions
auto convert(Foo& foo) { return FooWrapper{foo.get()}; }
// Your function
template <typename F, typename... Args>
auto convert_invoke(F&& f, Args&&... args) {
return f(convert(std::forward<Args>(args))...);
}
Demo
Related
Using C++ 17. I have the following:
template <typename T>
using ptr_t = std::shared_ptr<const T>;
class some_type;
class A { some_type foo() const; }
class B { some_type foo() const; }
class C { some_type foo(int) const; }
std::variant<ptr_t<A>, ptr_t<B>, ptr_t<C>>;
A variant holds shared_ptr(s) to different types. All expected to have function foo() that may be void or take a parameter. I will then have a visitor that would correctly dispatch foo, something like this (conceptually):
struct visitor
{
template <typename T>
ptr_t<some_type> operator()(const T& config) const
{
if constexpr (// determine if foo() of the underlying type of a shared_ptr can be called with int param)
return config->foo(15);
else
return config->foo();
}
is there a way to say this? I tried various ways but can't come with something that compiles. Template parameter, T, is ptr_t<A|B|C>.
std::is_invocable_v<Callable, Args...> is the way to go. Unfortunatelly, it will not compile just like that with if constexpr. It will either fail because "there is no operator()() overload", or there is no overload for operator taking Args....
I suggest you add a wrapper class for a callable and use it with a specialized alias template of std::variant instead of writing your own visitor. It will allow you to use std::visit seamlessly.
#include <type_traits>
#include <variant>
template <typename Callable>
class wrapped_callable
{
Callable c;
public:
wrapped_callable(Callable c)
: c(c)
{}
template <typename ... Args>
constexpr decltype(auto) operator()(Args &&... args) const
{
return _invoke(std::is_invocable<Callable, Args...>{}, c, std::forward<Args>(args)...);
}
private:
using _invocable = std::true_type;
using _non_invocable = std::false_type;
template <typename T, typename ... Args>
constexpr static decltype(auto) _invoke(_invocable, const T& t, Args &&... args)
{
return t(std::forward<Args>(args)...);
}
template <typename T, typename ... Args>
constexpr static decltype(auto) _invoke(_non_invocable, const T& t, Args ... args)
{
return t();
}
};
template <typename ... T>
using variant_callable = std::variant<wrapped_callable<T>...>;
struct int_callable
{
int operator()(int i) const
{
return i;
}
};
struct non_callable
{
int operator()() const
{
return 42;
}
};
#include <iostream>
int main()
{
using variant_t = variant_callable<int_callable, non_callable>;
// 23 is ignored, 42 is printed
std::visit([](const auto &callable){
std::cout << callable(23) << '\n';
}, variant_t{non_callable()});
// 23 is passed along and printed
std::visit([](const auto &callable){
std::cout << callable(23) << '\n';
}, variant_t{int_callable()});
}
Program returned: 0
42
23
https://godbolt.org/z/e6GzvW6n6
But The idea is not to have any specialization for all types in a variant as it will then require changing the visitor code every time a new type is added.
That is what template alias of std::variant<wrapped_callable<T>...> for. You just add append a new type to the list, that's it.
Take notice, that it does not depend on if constexpr. So if you manage to provide your own variant and is_invocable_v, it will work for C++14. For C++11 possibly, but some modifications regarding constexpr functions might be needed.
Of course you can implement your visitor in the same manner if you want to use std::shared_ptr istead of a callable.
But I don't see any reason to use:
visitor + smart pointer. Just use a smart pointer - it will give you runtime polymorphism in a "classic" way (via virtual inheritence)
why std::shared_ptr? Do you really need to share the ownership? Just stick with std::unique_ptr
I am trying to implement a resource protection class which would combine data along with a shared mutex (actually, QReadWriteLock, but it's similar). The class must provide the method to apply a user-defined function to the data when the lock is acquired. I would like this apply method to work differently depending on the function parameter (reference, const reference, or value). For example, when the user passes a function like int (const DataType &) it shouldn't block exclusively as we are just reading the data and, conversely, when the function has the signature like void (DataType &) that implies data modification, hence the exclusive lock is needed.
My first attempt was to use std::function:
template <typename T>
class Resource1
{
public:
template <typename Result>
Result apply(std::function<Result(T &)> &&f)
{
QWriteLocker locker(&this->lock); // acquire exclusive lock
return std::forward<std::function<Result(T &)>>(f)(this->data);
}
template <typename Result>
Result apply(std::function<Result(const T &)> &&f) const
{
QReadLocker locker(&this->lock); // acquire shared lock
return std::forward<std::function<Result (const T &)>>(f)(this->data);
}
private:
T data;
mutable QReadWriteLock lock;
};
But std::function doesn't seem to restrict parameter constness, so std::function<void (int &)> can easily accept void (const int &), which is not what I want. Also in this case it can't deduce lambda's result type, so I have to specify it manually:
Resource1<QList<int>> resource1;
resource1.apply<void>([](QList<int> &lst) { lst.append(11); }); // calls non-const version (ok)
resource1.apply<int>([](const QList<int> &lst) -> int { return lst.size(); }); // also calls non-const version (wrong)
My second attempt was to use std::result_of and return type SFINAE:
template <typename T>
class Resource2
{
public:
template <typename F>
typename std::result_of<F (T &)>::type apply(F &&f)
{
QWriteLocker locker(&this->lock); // lock exclusively
return std::forward<F>(f)(this->data);
}
template <typename F>
typename std::result_of<F (const T &)>::type apply(F &&f) const
{
QReadLocker locker(&this->lock); // lock non-exclusively
return std::forward<F>(f)(this->data);
}
private:
T data;
mutable QReadWriteLock lock;
};
Resource2<QList<int>> resource2;
resource2.apply([](QList<int> &lst) {lst.append(12); }); // calls non-const version (ok)
resource2.apply([](const QList<int> &lst) { return lst.size(); }); // also calls non-const version (wrong)
Mainly the same thing happens: as long as the object is non-const the mutable version of apply gets called and result_of doesn't restrict anything.
Is there any way to achieve this?
You may do the following
template <std::size_t N>
struct overload_priority : overload_priority<N - 1> {};
template <> struct overload_priority<0> {};
using low_priority = overload_priority<0>;
using high_priority = overload_priority<1>;
template <typename T>
class Resource
{
public:
template <typename F>
auto apply(F&& f) const
// -> decltype(apply_impl(std::forward<F>(f), high_priority{}))
{
return apply_impl(std::forward<F>(f), high_priority{});
}
template <typename F>
auto apply(F&& f)
// -> decltype(apply_impl(std::forward<F>(f), high_priority{}))
{
return apply_impl(std::forward<F>(f), high_priority{});
}
private:
template <typename F>
auto apply_impl(F&& f, low_priority) -> decltype(f(std::declval<T&>()))
{
std::cout << "ReadLock\n";
return std::forward<F>(f)(this->data);
}
template <typename F>
auto apply_impl(F&& f, high_priority) -> decltype(f(std::declval<const T&>())) const
{
std::cout << "WriteLock\n";
return std::forward<F>(f)(this->data);
}
private:
T data;
};
Demo
Jarod has given a workaround, but I'll explain why you cannot achieve that this regular way.
The problem is that:
Overload resolution prefers non-const member functions over const member functions when called from a non-const object
whatever object this signature void foo(A&) can accept, void foo(const A&) can also the same object. The latter even has a broader binding set than the former.
Hence, to solve it, you will have to at least defeat point 1 before getting to 2. As Jarod has done.
From your signatures (see my comment annotations):
template <typename F>
typename std::result_of<F (T &)>::type apply(F &&f) //non-const member function
{
return std::forward<F>(f)(this->data);
}
template <typename F>
typename std::result_of<F (const T &)>::type apply(F &&f) const //const member function
{
return std::forward<F>(f)(this->data);
}
When you call it like:
resource2.apply([](QList<int> &lst) {lst.append(12); }); //1
resource2.apply([](const QList<int> &lst) { return lst.size(); }); //2
First of all, remember that resource2 isn't a const reference. Hence, the non-const membr function of apply will always be prefered by Overload resolution.
Now, taking the case of the first call //1, Whatever that lambda is callable with, then then the second one is also callable with that object
A simplified mock-up of what you are trying to do is:
struct A{
template<typename Func>
void foo(Func&& f); //enable if we can call f(B&);
template<typename Func>
void foo(Func&& f) const; //enable if we can call f(const B&);
};
void bar1(B&);
void bar2(const B&);
int main(){
A a;
a.foo(bar1);
a.foo(bar2);
//bar1 and bar2 can be both called with lvalues
B b;
bar1(b);
bar2(b);
}
As I understand it, you want to discriminate a parameter that's a std::function that takes a const reference versus a non-constant reference.
The following SFINAE-based approach seems to work, using a helper specialization class:
#include <functional>
#include <iostream>
template<typename ...Args>
using void_t=void;
template<typename Result,
typename T,
typename lambda,
typename void_t=void> class apply_helper;
template <typename T>
class Resource1
{
public:
template <typename Result, typename lambda>
Result apply(lambda &&l)
{
return apply_helper<Result, T, lambda>::helper(std::forward<lambda>(l));
}
};
template<typename Result, typename T, typename lambda, typename void_t>
class apply_helper {
public:
static Result helper(lambda &&l)
{
std::cout << "T &" << std::endl;
T t;
return l(t);
}
};
template<typename Result, typename T, typename lambda>
class apply_helper<Result, T, lambda,
void_t<decltype( std::declval<lambda>()( std::declval<T>()))>> {
public:
static Result helper(lambda &&l)
{
std::cout << "const T &" << std::endl;
return l( T());
}
};
Resource1<int> test;
int main()
{
auto lambda1=std::function<char (const int &)>([](const int &i)
{
return (char)i;
});
auto lambda2=std::function<char (int &)>([](int &i)
{
return (char)i;
});
auto lambda3=[](const int &i) { return (char)i; };
auto lambda4=[](int &i) { return (char)i; };
test.apply<char>(lambda1);
test.apply<char>(lambda2);
test.apply<char>(lambda3);
test.apply<char>(lambda4);
}
Output:
const T &
T &
const T &
T &
Demo
The helper() static class in the specialized class can now be modified to take a this parameter, instead, and then use it to trampoline back into the original template's class's method.
As long as the capture lists of your lambdas are empty, you can rely on the fact that such a lambda decays to a function pointer.
It's suffice to discriminate between the two types.
It follows a minimal, working example:
#include<iostream>
template <typename T>
class Resource {
public:
template <typename Result>
Result apply(Result(*f)(T &)) {
std::cout << "non-const" << std::endl;
return f(this->data);
}
template <typename Result>
Result apply(Result(*f)(const T &)) const {
std::cout << "const" << std::endl;
return f(this->data);
}
private:
T data;
};
int main() {
Resource<int> resource;
resource.apply<void>([](int &lst) { });
resource.apply<int>([](const int &lst) -> int { return 42; });
}
I'm trying to implement bind function from boost library.
Below you can see the main struct bind_t with defined operator().
My question is as follows: Why should we specify in decltype in returning type of operator() returning type of call() explicitly as member function (if I remove this-> before call, the template argument deduction fails in g++.)
Also interesting, that using clang++ there's no such problem.
I have no idea, why this happens.
template <typename F, typename ... P>
struct bind_t {
private:
std::tuple<typename holder<P>::type...> p;
F func;
template <size_t ... N, typename ... Args>
auto call(index_list<N ...>, Args const& ... args) const -> decltype(func(std::get<N>(p)(args...)...)) {
return func(std::get<N>(p)(args...)...);
}
public:
bind_t(F f, P ... p):
p(std::move(p)...),
func(std::move(f))
{}
template <typename ... Args>
auto operator()(Args const& ... args) const -> decltype(this->call(typename indices_by_num<sizeof...(P)>::type(), args...)) {
typename indices_by_num<sizeof...(P)>::type indices;
return call(indices, args...);
}
};
full source of implementation
simple usecase
This is a gcc bug and is documented in the bug report decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type which says:
When using trailing return-type for member functions of a template
class, the 'this' pointer must be explicitly mentioned. This should
not be necessary (The implicit 'this' works with a non-template
class).
Example:
template <typename T>
struct DecltypeConstThis {
T f() const { return T{}; }
auto g() -> decltype(this->f()) { return this->f(); }
auto h() const -> decltype(f()) { return f(); } // this should work the same as g() above (with implicit 'this')
};
struct Working {
int f() const { return 0; }
auto h() const -> decltype(f()) { return 0; }
};
int main() {
Working w;
w.h();
DecltypeConstThis<int> d;
d.g();
d.h();
return 0;
}
The report was marked as fixed and it looks like this works starts working in gcc 5.1 (see it live).
Take a "lazy" constructor that might have the following interface:
template<class T>
struct LazyConstruct {
// accept any number of arguments,
// which would later be used to construct T
template<class... U>
LazyConstruct(U&&... u) {
// store the arguments somehow
}
T& get() {
if(!data) data.reset( new T( /* unpack the arguments */ ) );
return *data;
}
private:
std::unique_ptr<T> data;
};
What would be a nice way to implement this?
Here's a little bit of a convoluted way of doing what you want. The basic idea is to have LazyConstruct store the arguments pack in a tuple, and then unpack the tuple on demand to construct T.
template<class T, class... Args>
struct LazyConstruct {
// accept any number of arguments,
// which would later be used to construct T
template<class... U>
LazyConstruct(U&&... u)
: args(std::make_tuple(std::forward<U>(u)...))
{
}
T& get() {
if(!data) data = create(std::index_sequence_for<Args...>());
return *data;
}
template<std::size_t... I>
std::unique_ptr<T> create(std::index_sequence<I...>)
{
return std::unique_ptr<T>{new T(std::get<I>(args)...)};
}
private:
std::tuple<typename std::decay<Args>::type...> args;
std::unique_ptr<T> data;
};
I'm making use of C++14's std::index_sequence, if your standard library implementation does not ship this, then there are several examples on SO (this or this) showing how it can be implemented.
Finally a helper function template to construct LazyConstruct instances
template<class T, class... Args>
LazyConstruct<T, Args...> make_LazyConstruct(Args&&... args)
{
return LazyConstruct<T, Args...>{std::forward<Args>(args)...};
}
Live demo
Another version based on Alf's answer that uses std::function so that LazyConstruct's type doesn't change based on T's constructor signature.
template<class T>
struct LazyConstruct {
template<class... Args>
LazyConstruct(Args&&... args)
: holder([this, args = std::make_tuple(std::forward<Args>(args)...)]() {
return create(std::index_sequence_for<Args...>(), std::move(args));
})
{
}
T& get() {
if(!data) data = holder();
return *data;
}
template<std::size_t... I, class Tuple>
std::unique_ptr<T> create(std::index_sequence<I...>, Tuple args)
{
return std::unique_ptr<T>{new T(std::get<I>(args)...)};
}
private:
std::function<std::unique_ptr<T>()> holder;
std::unique_ptr<T> data;
};
Live demo
I am not sure about your question, but for lazy initialization I suggest you to use something along the lines of boost::optional<T>. You can delay initialization with it and you will not make use of a pointer and heap memory.
class MyClass {
public:
void f();
};
void anotherFunc(MyClass & c);
boost::optional<MyClass> mc; //Not initialized, empty, stack memory.
mc = MyClass{};
if (mc != boost::none)
mc->f();
anotherFunc(*mc);
Documentation is here: Boost.Optional
The easiest is probably to just capture the arguments in a lambda.
template<class T>
struct LazyConstruct {
// accept any number of arguments,
// which would later be used to construct T
template<class... U>
LazyConstruct(U&&... u)
: create( [=]() -> T* { return new T(u...); } )
{}
T& get() {
if(!data) data.reset( data.reset( create() ) );
return *data;
}
private:
std::unique_ptr<T> data;
std::function<auto()->T*> create;
};
Disclaimer: Code not touched by compiler's hands.
Note: While I'm unable right now to say exactly what's wrong with the idea (it's pretty late), lazy creation doesn't smell right, somehow. I suspect premature optimization.
As per the comment before. You want to delay and capture the arguments.
EDIT: Generalized solution, should work in C++11. Warnings: not tested. apply function is left as an exercise. See here for a possible implementation:
template <class T>
struct make {
template <class...Args>
T operator()(Args &&... args) const {
return T(std::forward<Args>(args)...);
}
};
template <class T, class... Args>
struct object_builder {
object_builder(Args... && args) :
captured_args_(std::forward<Args>(args)...) {}
T operator()() const {
return apply(make<T>{},
captured_args_);
}
private:
std::tuple<Args...> captured_args_;
};
template <class T, class...Args>
object_builder<T, Args...> make_object_builder(Args &&...args) {
return object_builder<T, Args...>(std::forward<Args>(args)...);
}
int main() {
//Create builders with captured arguments
auto scary_monster_builder =
make_object_builder<Monster>(scary, "big orc");
auto easy_monster_builder = make_object_builder<Monster>(easy,
"small orc");
//Instantiate objects with the captured arguments from before
auto a_scary_monster = scary_monster_builder();
auto an_easy_monster = easy_monster_builder();
}
I have an application where I'm building a function, marshal_and_apply, which calls some other function (or functor), f with some arguments. marshal_and_apply's job is to apply some special marshaling for the arguments depending on the type of f's parameters.
If one of f's parameters is of a special type, marshal_me<T>, then marshal_and_apply will marshal the parameter through some specially allocated storage before passing it to f. In order to perform the allocation, the storage requirements of all the parameters must be known to marshal_and_apply before any can be marshaled.
Some examples:
template<typename Function, typename... Args>
void marshal_and_apply(Function f, Args... args);
void func1(int x, int y);
void func2(marshal_me<int> x, int y);
void func3(marshal_me<int> x, marshal_me<int> y, marshal_me<int> z);
// this call would be equivalent to:
// func1(7,13)
marshal_and_apply(func1, 7, 13);
// this call would be equivalent to:
// auto storage = my_allocator(sizeof(int));
// auto x = marshal_me<int>(7, storage);
// func2(x, 13);
marshal_and_apply(func2, 7, 13);
// this call would be equivalent to:
// auto storage = my_allocator(sizeof(int) + sizeof(int) + sizeof(int));
// auto x = marshal_me<int>(7, storage);
// auto y = marshal_me<int>(13, storage + sizeof(int));
// auto z = marshal_me<int>(42, storage + sizeof(int) + sizeof(int));
// func3(x,y,z);
marshal_and_apply(func3, 7, 13, 42);
To solve this problem, it seems that marshal_and_apply requires a mechanism to inspect the types of f's parameters. I suspect this isn't possible in general, but it may be possible to recognize whether one of a special set of types (in this case, marshal_me<T>) is convertible to the type of a particular parameter.
How should I build marshal_and_apply?
Maybe something like this:
template<typename Function, typename... Args>
void marshal_and_apply(Function f, Args &&... args)
{
f(InspectAndModify<Args>::process(sizeof...(Args), std::forward<Args>(args))...);
}
Now define:
template <typename T> struct InspectAndModify
{
static T&& process(unsigned int N, T && t)
{
return std::forward<T>(t);
}
};
template <typename T> struct InspectAndModify<marshal_me<T>>
{
static T&& process(unsigned int N, marshal_me<T> && m)
{
/* ... */
}
};
Something completely different: This approach first dissects the function signature, and then performs a "static transform" on each pair of types, which is where you can insert the marshal_me specialization:
template <typename T> struct marshal_me { marshal_me(T) { } };
template <typename To, typename From> struct static_transform;
template <typename T> struct static_transform<T, T>
{
static T go(T t) { return t; }
};
template <typename T> struct static_transform<T, T&>
{
static T go(T & t) { return t; }
};
template <typename T> struct static_transform<marshal_me<T>, T>
{
static marshal_me<T> go(T && t) { return std::forward<T>(t); }
};
template<typename T, typename... Args>
struct marshal_impl
{
template <typename ...Urgs>
static T go(T(*f)(Urgs...), Args &&... args)
{
return f(static_transform<Urgs, Args>::go(std::forward<Args>(args))...);
}
};
template<typename Function, typename... Args>
void marshal_and_apply(Function f, Args &&... args)
{
marshal_impl<void, Args...>::go(static_cast<typename std::decay<Function>::type>(f),
std::forward<Args>(args)...);
}