Click here to Skip to main content
15,887,683 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I am having this below code for inorder traversal of tree:
void inOrder(struct node* r)
{
if (r==NULL)
return;

else{
inOrder(r->left);
printf("%d ", r->value);
inOrder(r->right);
    }
}


I am having this silly doubt:

When the bottom most left child is passed as root, it is not null.
In the next iteration root will be null (as left child of bottom most left child will be null) and it will encounter return.

Wont this return statement pass the control to main function (or wherever it is called) without printing anything?


Does return behave differently in recursion?

What I have tried:

<pre>
void inOrder(struct node* r)
{
if (r==NULL)
return;

else{
inOrder(r->left);
printf("%d ", r->value);
inOrder(r->right);
    }
}
Posted
Updated 1-Jun-17 10:12am

Every time you call a function, an area of memory called a stack is used to hold the context so that when the function exits you can continue from where you continued. It's called a stack, because it can hold many different function call contexts, and always adds a new context to the top when you call a function, and removes the last one from the top when you exit.

Suppose you have a tree:
    A
   / \
  B   C
 / \
D  E
You pass A to your function.
Is it null? No - Call it recursively with the right node: C. This stacks the context.
This time, you check if C is null. It isn't, so you recursively call the function passing it the C.Right node which is empty. This context gets stacks (so there are two contexts there now)
Check that against null. It is, so you return from the function immediately. Remove the top context, and restore it.
Execution continues from the statement immediately after the last call, where you were processing the C node. You print the Value "C" and repeat the process for the Left nodes.

Try it using the debugger, you'll soon get the idea!
 
Share this answer
 
If you return you come back to the calling function, not directly in main.

Debug the call stack to understand it. Some output always helps.
C++
void inOrder(struct node* r)
{
printf("inoder %d ",(int) r);//debug output
if (r==NULL)
return;
 else{
//do your recursion work
printf("l-call: %d ", l->value);
inOrder(r->left);
printf("r-call: %d ", r->value);
inOrder(r->right);
    }
}
 
Share this answer
 
No. It will return, sure, but only one level, not all the way back to the original caller. Build a simple tree of say 5 or 6 nodes, then step through your code with a debugger. Watch the nested calls and returns.
 
Share this answer
 
C++
void main()
{
	struct node *pn;
	int a = 5, b = 8, c;
	
	...
	<some code>
	...
	inorder(pn);
	c = a + b;     // address of this instruction is 12345680
	<some more code>
}

int fun()
{
	struct node n;
	
	...
	<some code>
	....
	
	inorder(&n);
	getchar();   // address of this instruction is 12345760
	<some more code>
}

void inorder(struct node *r)
{
	if (r==NULL)
		return;
	else
	{
		inOrder(r->left);
		printf("%d ", r->value);  // address of this instruction is 12345900
		inOrder(r->right);
	}
}

/*
	JUST before calling inorder()
	in the call from main() the value 12345680 is pushed onto the stack
	in the call from fun()  the value 12345760 is pushed onto the stack
	in the (recursive) call from inorder()  the value 12345900 is pushed onto the stack
	
	i.e. in each case the address of the next instruction (immediately following the function call) is pushed onto the stack
	so that processing continues from this point (next instruction) in the CALLER after the called function completes normally 
		(end of function OR  'return' instruction in the middle of the function)
	It makes no difference whether the call is recursive or not.
	if you have some idea of 32 bit x86 registers 
		'eip' always holds the address of the instruction to be executed next
		'esp' points to the last value pushed on the stack - 
			this is the return address (12345680 / 12345760 / 12345900) in our example
		the 'return' instruction will result in something like this (in C syntax):
			eip = *esp++; // esp++ since stack grows downward (generally including x86)
			
			Since 'esp' points to these values, the return address is automatically assigned to 'eip'
		So processing continues from whatever instruction 'eip' points to i.e. next instruction in CALLER.

*/
 
Share this answer
 
Quote:
I am having this silly doubt

There is a tool that allow you to see what your code is doing, its name is debugger. Mastering the debugger is not optional, it is mandatory for any programmer, no exception.
It is also a great learning tool because it show you reality and you can see which expectation match reality.
When you don't understand what your code is doing or why it does what it does, the answer is debugger.
Use the debugger to see what your code is doing. Just set a breakpoint and see your code performing, the debugger allow you to execute lines 1 by 1 and to inspect variables as it execute, it is an incredible learning tool.

Debugger - Wikipedia, the free encyclopedia[^]
Mastering Debugging in Visual Studio 2010 - A Beginner's Guide[^]
Basic Debugging with Visual Studio 2010 - YouTube[^]
The debugger is here to show you what your code is doing and your task is to compare with what it should do.
There is no magic in the debugger, it don't find bugs, it just help you to. When the code don't do what is expected, you are close to a bug.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900