Order of operations on functions [closed] - c++

Question

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed last month.
Improve this question
On today's adventofcode, we had a pathfinding problem, with persistent states over multiple rounds.
I created a function called solve(startPoint, endPoint) which would calculate the steps to go from one waypoint to the other.
The code that worked fine:
int first = solve(start, end);
int second = solve(end, start);
int third = solve(start, end);
return first + second + third;
The code that did not work:
return solve(start, end) + solve(end, start) + solve(start, end);
And neither did
return (((solve(start, end)) + solve(end, start)) + solve(start, end));
 
How can I return the accumulated value in one line, without running in some sort of order issue?

Answer 1

The order of parts of a composed expression is not specified in C++ (see https://en.cppreference.com/w/cpp/language/eval_order). Therefore, it is not possible to gather these function calls in a single expression and guarantee a particular order of evaluation.

Answer 2

> How can I return the accumulated value in one line, without running in some sort of order issue?
Try this:
int a, b, c;
return (a = solve(start, end), b = solve(start, end), c = solve(start, end), a + b + c);
It guarantees the evaluation in order from left to right.
From eval_order:
Every value computation and side effect of the first (left) argument of the built-in comma operator , is sequenced before every value computation and side effect of the second (right) argument.

Answer 3

With persistent states, that code looks like this:
int a = c++ + c++ + c++;
there is no strict ordering about these operations. Partial results may even be cached in different CPU registers and get false result, even if the first c++ increments first, the second and third could be already cached on different CPU-registers for speed optimization, because there are likely multiple adder pipelines in a cpu core that can do it in (instruction-level) parallelism.
Try implementing a chain-calculation API like this:
return solve(s,e).addSolve(e,s).addSolve(s,e).result;
Here, the evaluation has to start from first and end at the last because this is just multiple lines of codes in disguise. Something like this:
class FOO
{
public:
BAR result;
FOO(){ result=0;}
FOO(BAR se){ result=se; }
// assuming solution is s+e
FOO solve(BAR s, BAR e)
{
return FOO(s+e);
}
FOO addSolve(BAR s, Bar e)
{
return FOO(result+s+e);
}
};
Ofcourse the upper example does not save the states in the original object. You need something like this really:
class FOO
{
public:
std::shared_ptr<BAR> result;
// creates original store
FOO()
{
result = std::make_shared<BAR>();
*result=0;
}
// re-uses original
FOO(BAR se, std::shared_ptr<BAR> original)
{
result = original;
*result=se;
}
// assuming solution is s+e
FOO solve(BAR s, BAR e)
{
return FOO(s+e,result);
}
FOO addSolve(BAR s, Bar e)
{
return FOO(*result + s + e,result);
}
};
So that you can still use the original object (the one that was created first) for the result.
Even if original object goes out of scope, the second and the third instances still have the exact same result.
If the initial conditions (parameterless default constructor) meet the requirements of addSolve, then you could simply call same addSolve method 3 times after renaming it to just solve:
// dereferencing explicitly
return *foo.solve(s,e).solve(e,s).solve(s,e).result;
// or implicitly from a method
return foo.solve(s,e).solve(e,s).solve(s,e).getResult();

Answer 4

If you make solve an object that holds the parameters and allows for lazy evaluation, you can overload the + operator for this type to guarantee the order of evaluation:
/**
* object simply stores the parameters for evaluation in operator+
*/
struct solve
{
int m_a;
int m_b;
constexpr solve(int a, int b) noexcept
: m_a(a), m_b(b)
{
}
int operator()() const
{
std::cout << "evaluating solve(" << m_a << ", " << m_b << ")\n";
return m_a + m_b;
}
};
int operator+(solve const& s1, solve const& s2)
{
// do operation of the first operand before the second
auto v1 = s1();
return v1 + s2();
}
int operator+(int s1, solve const& s2)
{
// first operand is already evaluated
return s1 + s2();
}
int main()
{
auto result = solve(1, 2) + solve(3, 4) + solve(5, 6);
std::cout << result << '\n';
return 0;
}
Output:
evaluating solve(1, 2)
evaluating solve(3, 4)
evaluating solve(5, 6)
21
In real code I recommend adding the constexpr modifier to solve::operator()() and the + operators, if possible btw...
Note that this may not be the best idea, since seeing the expression solve(1, 2) + solve(3, 4) + solve(5, 6) it's not obvious, that an order of evaluation is enforced here...