This is the sort of "who gives a sh*t??" lump of code that's often chucked at you during interviews. One of the best ways of working out what it's doing is to refactor it so it's more readable (even on a bit of paper). One pass through gave me this:
#include<iostream>
int fun( int a, int b )
{
return a + (b == 1 ) ? 0 : fun( a, b - 1 );
}
int main()
{
std::cout << "the result is" << fun( 3, 5 );
char wait_for; std::cin >> wait_for;
}
When you do that the recursive function looks a lot simpler. To analyse what it does (a) work out where the recursion terminates and (b) work back up the call stack accumulating what each call has done. If you do that you won't need to dry run the code in a lot of cases as it's fairly obvious what's happening as soon as you know how many calls it makes.
Incidentally the "refactor to understand" technique is great to work out what code you've never seen before does AND it improves the quality of it. What's not to like?
Cheers,
Ash