what is the best way of tracing code on paper

**~~transgalactic2~~** · 03-29-2009

i got this code
its very complicated
how to trace it in the most afficient way?

Code:

#include <stdio.h>
void print(int *arr, int n);
int what(int *parts, int size, int number, int *set, int count);

void print(int *arr, int n){
	int i ;
	for (i=0; i<n; i++)
		printf(" %d",arr[i]);
	puts("");
}

int what(int *parts, int size, int number, int *set, int count){
	int res=0,i;

	if(!number){
		print(set, count);
		return 1;
	}

	for(i=0; i<size; i++)
	  if(number >= parts[i]){
		set[count] = parts [i];
		res += what(parts, size, number-parts[i], set,count+1);
	  }
	return res;
}
void main(){
	int parts[]={3, 1, 2}, set[4], result;
	result = what(parts, 3, 4, set, 0);
	printf("%d\n", result);
}

**MK27** · 03-29-2009

With your eyes closed, using a pretzel, a hornet, and some plastic gears.

What do you mean by "trace"?

**~~transgalactic2~~** · 03-29-2009

i mean by finding out what the output

**ಠ_ಠ** · 03-29-2009

do 1 step at a time

**MK27** · 03-29-2009

People will doubtless attack me again for this, but I still think printf is the best tool you could ever want for debugging, tracing, and so on. Hopefully the contraption you use to write/work with code has some way of setting a user "key binding" or macro. I added one so that whenever I hit F1, this appears in front of the cursor:

Code:

printf("\n); fflush(stdout);

which saves quite a bit of typing, and if left on a line by itself is quick and easy to remove as well. Then you just throw in the variables whose value you want to check, maybe adding a little note (such as the name of the current function) just so you don't confuse yourself with the output.

With larger projects, I've actually made those permanent so that I can use them to trace errors:

Code:

// global:
int debug=0;
/* then use a "getopt" style switch so you can set debug=1 if you invoke the program with this "secret" switch */
// all over the place:
if (debug) { printf("somefunc()  myvar=%s\n", myvar); fflush(stdout); }

The fflush(stdout) is absolutely crucial, otherwise when tracking a crash, execution could be halted after the printf line, but before the stdout buffer is cleared, meaning you won't be able to tell. With fflush(), the printf statement will appear even if the very next line causes a crash.

It May Very Well Be that you would be better off, as a novice, learning how to use printf this way, than you would be if you spent the same amount of time trying to learn the "advanced" features of your particular IDE.

Notice: this is very much in keeping with the "one step at a time" concept. C is procedural.

**tabstop** · 03-29-2009

I think the question is not so much debugging as "I don't know what this piece of code is". This is also suggested by the function name "what", and the fact that this is an exam question.

**MK27** · 03-29-2009

Originally Posted by tabstop

I think the question is not so much debugging as "I don't know what this piece of code is". This is also suggested by the function name "what", and the fact that this is an exam question.

Hey! That's more ammo for me -- I'm sure your mind will be better adapted to looking at code thru the practice of looking at code, not some bunch of pull down menu options and output windows (and worse yet, something that will highlight a problem for you).

It would seem to me that the IDE developed according to the needs of already professional programmers and not necessarily those of students, which is to say "ease of use" can create a set of complications totally divorced from the ones it may have hidden or eliminated.

**tabstop** · 03-29-2009

Originally Posted by MK27

Hey! That's more ammo for me -- I'm sure your mind will be better adapted to looking at code thru the practice of looking at code, not some bunch of pull down menu options and output windows (and worse yet, something that will highlight a problem for you).

It would seem to me that the IDE developed according to the needs of already professional programmers and not necessarily those of students, which is to say "ease of use" can create a set of complications totally divorced from the ones it may have hidden or eliminated.

I'm not saying that printf can't be better to learn from than a full-blown debugger. I'm saying that most exam blue books don't have printf implemented, and since presumably most of the grade on the question will come from you having the variables laid out, with the various states the machine goes through visible (albeit scratched out as the values of the variable change), being able to do it yourself without machine assistance of any kind is the most valuable thing of all. (Not to mention the ability it gives you to look at a piece of code, say on an internet forum or whatever, and find the error without having to type it in/cut and paste it, add printf statements, and examine the output.)

**MK27** · 03-29-2009

Tish!#@ that is nasty dude. I hate using a pen. There must be some preconcieved method of noting recursive functions -- don't they exist in historical mathematics along with set theory, etc? I don't read enough theory, for sure.

Start with the limiting case of the recursion, that is the case in which a defined finite number is returned, this one like most I think iterates 1.

Thread: what is the best way of tracing code on paper

Thread Tools

Search Thread

Display

what is the best way of tracing code on paper

what is the best way of tracing code on paper

sounds like a job for printf

Similar Threads

Enforcing Machine Code Restrictions?

Proposal: Code colouring

Values changing without reason?

PRS Help

Interface Question