std::async and lambda function in C++ gives no associated state - c++

I'm trying to obtain a better performance in my program by using async whenever this is convenient. My program compiles, but I get the following error every time I use a function containing async calls:
C++ exception with description "No associated state"
The way I am trying to call async with a lambda is e.g. as follows:
auto f = [this](const Cursor& c){ return this->getAbsIndex(c); };
auto nodeAbsIndex = std::async(f,node); // node is const Cursor&
auto otherAbsIndex = std::async(f,other); // other too
size_t from = std::min(nodeAbsIndex.get(), otherAbsIndex.get());
size_t to = std::max(nodeAbsIndex.get(), otherAbsIndex.get());
Signature of the function to call is as follows:
uint64_t getAbsIndex(const Cursor& c) const
What am I doing wrong here? Thanks for any hints!
Diego

You can't call get() twice on the same future. Read documentation carefully (the part regarding valid()): http://en.cppreference.com/w/cpp/thread/future/get
On a side note, implicitly casting uint64_t to size_t is not good. The latter could be of smaller size.

Related

Is this defining a lambda function and assigning the function pointer to a value at the same time?

Still many C++ codes are so difficult for me to understand..
Below is a code snippet from dlib (http://dlib.net file : dlib/external/pybind11/include/pybind11/pybind11.h)
It's a member function definition of class cpp_function and I didn't try to understand the code(no time to do that..that's sad..). I can't understand the syntax in the line I put *** this line! comment at below. I understand the lambda function(unnamed function), so is it assigning a function pointer to rec->impl, the function taking function_call &call as argument and returning handle? So, it looks like defining a function and at the same time assigning the function pointer to a variable. Having asked it, it looks so now.. Please someone confirm this.
void initialize(Func &&f, Return (*)(Args...), const Extra&... extra) {
using namespace detail;
struct capture { remove_reference_t<Func> f; };
...
rec->impl = [](function_call &call) -> handle { // <=== *** this line!
cast_in args_converter;
/* Try to cast the function arguments into the C++ domain */
if (!args_converter.load_args(call))
return PYBIND11_TRY_NEXT_OVERLOAD;
/* Invoke call policy pre-call hook */
process_attributes<Extra...>::precall(call);
/* Get a pointer to the capture object */
auto data = (sizeof(capture) <= sizeof(call.func.data)
? &call.func.data : call.func.data[0]);
capture *cap = const_cast<capture *>(reinterpret_cast<const capture *>(data));
/* Override policy for rvalues -- usually to enforce rvp::move on an rvalue */
const auto policy = return_value_policy_override<Return>::policy(call.func.policy);
/* Function scope guard -- defaults to the compile-to-nothing `void_type` */
using Guard = extract_guard_t<Extra...>;
/* Perform the function call */
handle result = cast_out::cast(
std::move(args_converter).template call<Return, Guard>(cap->f), policy, call.parent);
/* Invoke call policy post-call hook */
process_attributes<Extra...>::postcall(call, result);
return result;
};
...
using FunctionType = Return (*)(Args...);
constexpr bool is_function_ptr =
std::is_convertible<Func, FunctionType>::value &&
sizeof(capture) == sizeof(void *);
if (is_function_ptr) {
rec->is_stateless = true;
rec->data[1] = const_cast<void *>(reinterpret_cast<const void *>(&typeid(FunctionType)));
}
}
rec->impl = [](function_call &call) -> handle
creates a lambda which takes one argument of type function_call and returns a handle, then assigns it to rec->impl.
As lambdas are basically unnamed structs, they also have unnamed types. Since rec->impl obviously exists already and is thus not templatized on the lambda type, the lambda gets converted to some other type during the assignment. (Note: there could however be a templatized and overloaded operator= here)
Typically such types which can take lambdas are either std::function or function pointers as stateless lambdas can be converted to function pointers.

What's the proper way to have a Task that calls an arbitrary function with a known, specific return type?

I have a value which is expensive to calculate and can be asked for ahead of time--something like a lazily initiated value whose initialization is actually done at the moment of definition, but in a different thread. My immediate thought was to use parallelism.-Task seems purpose-built for this exact use-case. So, let's put it in a class:
class Foo
{
import std.parallelism : Task,task;
static int calculate(int a, int b)
{
return a+b;
}
private Task!(calculate,int,int)* ourTask;
private int _val;
int val()
{
return ourTask.workForce();
}
this(int a, int b)
{
ourTask = task!calculate(a,b);
}
}
That seems all well and good... except when I want the task to be based on a non-static method, in which case I want to make the task a delegate, in which case I start having to do stuff like this:
private typeof(task(&classFunc)) working;
And then, as it turns out, typeof(task(&classFunc)), when it's asked for outside of a function body, is actually Task!(run,ReturnType!classFunc function(Parameters!classFunc))*, which you may notice is not the type actually returned by runtime function calls of that. That would be Task!(run,ReturnType!classFunc delegate(Parameters!classFunc))*, which requires me to cast to typeof(working) when I actually call task(&classFunc). This is all extremely hackish feeling.
This was my attempt at a general template solution:
/**
Provides a transparent wrapper that allows for lazy
setting of variables. When lazySet!!func(args) is called
on the value, the function will be called in a new thread;
as soon as the value's access is attempted, it'll return the
result of the task, blocking if it's not done calculating.
Accessing the value is as simple as using it like the
type it's templated for--see the unit test.
*/
shared struct LazySet(T)
{
/// You can set the value directly, as normal--this throws away the current task.
void opAssign(T n)
{
import core.atomic : atomicStore;
working = false;
atomicStore(_val,n);
}
import std.traits : ReturnType;
/**
Called the same way as std.parallelism.task;
after this is called, the next attempt to access
the value will result in the value being set from
the result of the given function before it's returned.
If the task isn't done, it'll wait on the task to be done
once accessed, using workForce.
*/
void lazySet(alias func,Args...)(Args args)
if(is(ReturnType!func == T))
{
import std.parallelism : task,taskPool;
auto t = task!func(args);
taskPool.put(t);
curTask = (() => t.workForce);
working = true;
}
/// ditto
void lazySet(F,Args...)(F fpOrDelegate, ref Args args)
if(is(ReturnType!F == T))
{
import std.parallelism : task,taskPool;
auto t = task(fpOrDelegate,args);
taskPool.put(t);
curTask = (() => t.workForce);
working = true;
}
private:
T _val;
T delegate() curTask;
bool working = false;
T val()
{
import core.atomic : atomicStore,atomicLoad;
if(working)
{
atomicStore(_val,curTask());
working = false;
}
return atomicLoad(_val);
}
// alias this is inherently public
alias val this;
}
This lets me call lazySet using any function, function pointer or delegate that returns T, and then it'll calculate the value in parallel and return it, fully calculated, next time anything tries to access the underlying value, exactly as I wanted. Unit tests I wrote to describe its functionality pass, etc., it works perfectly.
But one thing's bothering me:
curTask = (() => t.workForce);
Moving the Task around by way of creating a lambda on-the-spot that happens to have the Task in its context still seems like I'm trying to "pull one over" on the language, even if it's less "hackish-feeling" than all the casting from earlier.
Am I missing some obvious language feature that would allow me to do this more "elegantly"?
Templates that take an alias function parameter (such as the Task family) are finicky regarding their actual type, as they can receive any type of function as parameter (including in-place delegates that get inferred themselves). As the actual function that gets called is part of the type itself, you would have to pass it to your custom struct to be able to save the Task directly.
As for the legitimacy of your solution, there is nothing wrong with storing lambdas to interact with complicated (or "hidden") types later.
An alternative is to store a pointer to &t.workForce directly.
Also, in your T val() two threads could enter if(working) at the same time, but I guess due to the atomic store it wouldn't really break anything - anyway, that could be fixed by core.atomic.cas.

c++ check at compile time if a function is called

Possible duplicates I'll explain at the bottom.
I was wondering if it is possible to do a compile time check to see if a function is called before another function.
My use case looks something like this:
auto f = foo();
if(!f.isOk())
return f.getError();
auto v = f.value();
So in this case I would want to get a compile time error if the user did not call isOk before calling value.
As far as I know and searched it does not seem possible but I wanted to ask here just to be sure I didn't miss any c++ magic.
FauxDupes:
How to check at compile time that a function may be called at compile time?
This is about knowing wether your function is a constexpr function. I want to know if one function has been called before the other has been called.
What you want is not possible directly without changing your design substantially.
What you can do is enforce calling always both by wrapping them in a single call:
??? foo(const F& f) {
return f.isOk() ? f.value() : f.getError();
}
However, this just shifts the problem to choosing the return type. You could return a std::variant or with some changes on the design a std::optional, but whatever you do it will be left to the caller to check what actually has been returned.
Don't assume the most stupid user and don't try to protect them from any possible mistake. Instead assume that they do read documentation.
Having to check whether a returned value is valid is a quite common pattern: functions that return a pointer can return a null-pointer, functions returning an iterator can return the end iterator. Such cases are well documented and a responsible caller will check if the returned value is valid.
To get further inspiration I refer you to std::optional, a quite modern addition to C++, which also heavily relies on the user to know what they are dealing with.
PS: Just as one counter-example, a user might write code like this, which makes it impossible to make the desired check at compile time with your current design:
int n;
std::cin >> n;
auto f = foo();
if(n > 10 && !f.isOk())
return f.getError();
auto v = f.value();
One strategy for this kind of thing is to leverage __attribute__((warn_unused_result)) (for GCC) or _Check_return_ (msvc).
Then, change foo() to return the error condition:
SomeObj obj;
auto result = foo(obj);
This will nudge the caller into handling the error. Of course there are obvious limitations: foo() cannot be a constructor, for example, and the caller cannot use auto for the typename.
One way to ensure order is to transform the temporary dependency into physical dependency:
Move method F::getError() and F::value() into their own structure wrapper (Error, Value).
Change bool F::isOk() to something like:
std::variant<Error, Value> F::isOk()
Then, you cannot use Error::getError or Value::value() before calling isOk, as expected:
auto f = foo();
auto isOk = f.isOk();
if (auto* e = std::get_if<Error>(&isOk)) // Or std::visit
return e->getError();
auto& value = std::get<Value>(&isOk);
auto v = value.value();

Reuse of variable of type auto

I have a special class to be used as return type of methods, containing the wanted value or in case of failure an error message which is even cascading from earlier errors. It works as expected.
As the returned type is differently complex I like to use the keyword auto. But when using a lot of methods I have to create new return variables.
A typical part of code looks like this:
auto ret1 = methodA();
if(ret1.isValid()...
auto ret2 = methodB();
if(ret2.isValid()...
I dont like to always create a new variable. But I like the elegant way of error handling. Using a more dump return type like an error code in integer would solve the problem but then I have no benefit from the error handling return type.
Is there any trick to reuse the first return variable ret1?
You would have to create new scopes to reuse the variable name for a different variable, like:
{
auto ret = methodA();
if (ret.isValid()) ...
}
{
auto ret = methodB();
if (ret.isValid()) ...
}
You can also take advantage of the scope created by if, placing the init-statement inside:
if (auto ret = methodA(); ret.isValid()) ...
if (auto ret = methodB(); ret.isValid()) ...
auto is not a type.
It is a keyword, that says "put the type here for me, by deducing it from the initial value". That occurs during compilation, once.
You cannot reuse ret1 to store an object of a different type, whether you use auto or not.
This shouldn't really be a problem. If you're concerned about "running out of names", or "having many similar names", your names are not descriptive enough and/or your scopes aren't tight enough.
auto is not a type. In auto foo = bar(); the compiler simply figures out what type bar() actually returns and substitutes that in. So if bar() returns int then that's the type of foo, if it returns bool then that is the type of foo. And once the type that auto should be replaced with (the first time) has been determined, then it can never change. auto doesn't mean "variable type" it just means "hey compiler, I'm too lazy to figure out the type to put here, please do it for me", but there is no difference what-so-ever compared to you just writing the final type yourself.
So, you can reuse the variable if what you assign to it the second time is of the same type as the first time - otherwise not.
I dont like to always create a new variable.
Much better is to create a const variable:
const auto ret1 = methodA();
if(ret1.isValid()...
const auto ret2 = methodB();
if(ret2.isValid()...
In this case you need to make const all the methods like isValid, but that is even better: "is" shouldn't have side effects and modify the state.
Next step is to remove the temp variable at all:
if(methodA().isValid()) {
...
}
if(methodB().isValid()) {
...
}
The alternative is to wrap each function call into a block:
{
const auto ret = methodA();
if(ret.isValid()...
}
{
const auto ret = methodB();
if(ret.isValid()...
}
This allows you to reuse the const variable name.
Each block becomes a candidate for extraction into a separate function (see Uncle Bob in "Clean Code").

Can't call a lazy lambda function with parameters via boost::phoenix::function

I tried to call boost::phoenix::function based on lambda function with parameters and failed. If I call it without parameters in such a way:
const auto closure = [](){
cout<< "test" << endl;
};
typedef decltype(closure) ClosureType;
const boost::phoenix::function<ClosureType> lazyFunc (std::move(closure));
lazyFunc()();
all compiles nice. But when I declare at least one parameter of lambda:
const auto closure = [](int& param) { cout<<"Test" << param << endl; };
typedef decltype(closure) ClosureType;
const boost::phoenix::function<ClosureType> lazyFunc (std::move(closure));
lazyFunc(arg1)(a);
compilation fails with tremendous stack trace deep inside of boost::result_of
Assuming the error points to somewhere deep inside Boost.ResultOf (as seen in this demo), that would be because the closure type of a lambda expression does not implement the ResultOf protocol.
A somewhat simple workaround to that is to define BOOST_RESULT_OF_USE_DECLTYPE, which makes boost::result_of bypass its own ResultOf protocol by instead using decltype to compute return types. This is not enabled by default because not many compilers (at the time of the release of Boost 1.51) are conformant enough for this feature to work; it is planned that this symbol be defined automatically (by Boost.Config) for those compilers that can deal with it for 1.52.
Here is a demo of what it looks like to use Boost.Phoenix with a decltype-powered boost::result_of. I had to change the int& to int const& because i is apparently being forwarded as a const int. This appears to be a fundamental limitation of boost::phoenix::function, using boost::phoenix::val doesn't have this problem.