dont konw what to do next.

**negevy** · 09-08-2005

Im doing the tower of hanoi but without recursion.
Im trying to do it with linked list.
I have managed to write the algoritm but I dont know how to make it repeat it self until it finds the solution.
if I check the debugger Im getting the first step correctly but then It needs to use the head again and use the same algoritm on it and so on untill it finds the first solution.

Code:

#include <stdio.h>
#include <stdlib.h>
 typedef struct hanoi{
	int nod ; // number of disks //
	int spole ; // source pole number //
	int dpole; // destination pole number //
	struct hanoi *next;
} hanoi;

hanoi *insert(hanoi *head );

void main()
{
hanoi *head ;


head =(hanoi *) malloc (sizeof (hanoi)) ;


head->next=NULL;


printf("please, enter the number of disks\n") ;
scanf("%d", &head->nod);
printf("the source pole number\n") ;
scanf("%d", &head->spole);
printf("the destination pole number\n");
scanf("%d", &head->dpole);

insert(head);




}

hanoi *insert(hanoi *head )
{
	hanoi *temp;
	
	temp =(hanoi *) malloc (sizeof ( hanoi)) ; 
	temp->next =( hanoi *) malloc (sizeof ( hanoi)) ;
	temp->next->next = (hanoi *) malloc (sizeof ( hanoi)) ;
	
	// nod //
	temp->nod = head->nod -1 ;
    temp->next->next->nod = head->nod -1 ;
    temp->next->nod = 1 ;
	
	// spole //
    temp->spole = head->spole  ;
    temp->next->spole = head->spole ;
    temp->next->next->spole=6-head->spole-head->dpole;
    
    // dpole //
    temp->next->dpole = head->dpole ;
    temp->next->next->dpole = head->dpole ;
	temp->dpole = head->spole=6-head->spole-head->dpole;
    
	
	temp->next->next->next=NULL;
	return temp;
	
	
	
	
	
	
}

**Salem** · 09-08-2005

> void main()
Stop using void main, start using int main
See the Avatar, read the FAQ, search the board.

> head =(hanoi *) malloc (sizeof (hanoi)) ;
Stop casting malloc
Read the FAQ (this is getting old)

> insert(head);
So you ignore the return result...

**Ancient Dragon** · 09-08-2005

Why do you insist that people stop casting malloc()? There is not anything wrong with doing that. In C it is unnecessary, but not illegal. In C++ it is required.

**quzah** · 09-08-2005

Read the FAQ. You might as well ask, "Why tell people not to use a 'char' for EOF comparison? There's not anything wrong with doing that. In C it is [snip] not illegal!" Sure it's not. It doesn't make it right though.

Seriously, why answer questions at all if you're not going to tell people the better way to do something? Why not just show them half-assed ways to get the job done? I mean, from now on, I may as well just tell them all to use gets for all input! It's not illegal in C!

Quzah.

**negevy** · 09-08-2005

so what do I have to do next?

**swoopy** · 09-08-2005

Sort of reminds me of the poster who wants to use the register keyword. "It's a good habit to get into, and it certainly can't hurt."

**Narf** · 09-08-2005

There is not anything wrong with doing that.

Except that it hides the warning that you'll get if there is something wrong. Like forgetting to include stdlib.h. That happens to me all the time. I use malloc() but forget to include stdlib.h. If I automatically put a cast on malloc() then it would be that much harder to find the bug.

In C it is unnecessary, but not illegal. In C++ it is required.

A bunch of people will tell you that if you want C++, write good C++. I'm not one of those people because I write libraries that need to be used in both languages. But that doesn't mean I cast my malloc() calls right away. I always test on C first to ensure that it works on the less feature rich language. Then I port to C++ and test there to take advantage of the stricter type checking. Then I test on C again to make sure that the port didn't break anything.

I've caught countless bugs that would go unnoticed if I weren't so anal about correctness. And several of those bugs would come from casts that are unnecessary in C, but required in C++. Cast when you need to, but I believe in working with the compiler, not fighting against it. And working with the compiler means taking advantage of the errors and warnings that it can give you to make your code better.

Am I against casting malloc()? Hell no. But I am against casting malloc() right away just because you "know" it'll be needed when/if you port to C++. I don't cast malloc() unless I'm writing something that needs to be both C and C++ right now. Porting C to C++ isn't that hard, so if my C code isn't going to be used as C++ but might be in the future, I postpone the port until that time.

so what do I have to do next?

It's instructive to convert recursion to iteration using a stack. That's not the best way to solve the Hanoi problem, but you can apply what you learn from it elsewhere. That's a good thing. But if you spend some time thinking, you can come up with a bunch of ways to solve the problem without even considering the recursive solution. Here's on fun solution. See if you can figure it out:

Code:

#include <stdio.h>

#define N 3

int main() {
  int d[N + 2], s[N + 2];
  int i, dir = N % 2, temp;

  for (i = 0; i <= N + 1; i++) {
    d[i] = 1;
    s[i] = i + 1;
  }

  while (1) {
    i = s[0];
    if (i > N) break;
    temp = (d[i] + (i % 2 ? dir : 1 - dir)) % 3 + 1;
    printf("%d from %d to %d\n", i, d[i], temp);
    d[i] = temp;
    s[0] = 1;
    s[i-1] = s[i];
    s[i] = i + 1;
  }
}

But I don't recommend turning it in as homework, if this is a school assignment. It's advanced enough to get you a failing grade at the least, and expelled for cheating at the most.

**Ancient Dragon** · 09-08-2005

Originally Posted by Narf

Except that it hides the warning that you'll get if there is something wrong. Like forgetting to include stdlib.h. That happens to me all the time. I use malloc() but forget to include stdlib.h. If I automatically put a cast on malloc() then it would be that much harder to find the bug.

Then you do not do any typecasting at all for any reason

Yes, I read that silly 2-year-old FAQ that discussed typecasting malloc(). The fear of forgetting to include stdlib.h is probably one of the funniest excuses I've read to date -- and I havn't been in college since 1980.

**Salem** · 09-08-2005

> The fear of forgetting to include stdlib.h is probably one of the funniest excuses I've read
But why go out of your way to introduce places for bugs to hide which have no business being introduced in the first place?

p = malloc ( numRequired * sizeof *p );
No additional casting, and no further editing required should you change the type of p, and no bloody casts. Since it works for all types and all amounts, it means you can get into the habit of always doing the right thing without too much thinking about. Like braces which are optional, if you make them compulsory, then you'll always do the right thing.

Compare with
int *p = (int*)malloc ( numRequired * sizeof(int) );
Gee, three!!! things need to be changed, and absolutely NO warnings at all if you don't manage to change all 3 at the same time. Save for perhaps random segfaults much later on.

And if you should happen to forget the cast, or try and compile it with C++, you'll get some handy warnings telling you that there is something you need to be paying attention to.
Either including the right header, or seriously considering using the right compiler or changing malloc/free into new/delete.

**Narf** · 09-08-2005

The fear of forgetting to include stdlib.h is probably one of the funniest excuses I've read to date

Why? I don't know about you, but I'm not perfect. I forget to include stdlib.h all the time, and I'm also aware of legitimate problems that can occur if there's no prototype in scope for malloc. But if that doesn't do it for you, how about less typing, easier maintenance, and cleaner code? There are good arguments for both sides, but I think in general the arguments to not cast make more sense.

Then you do not do any typecasting at all for any reason

Am I just overly flexible to be able to see both sides of an argument and pick the most reasonable solution? Because a lot of people--like you--take what I say and mangle it to the most extreme possible interpretation. Or am I just really bad at expressing myself and nobody understands me?

**Ancient Dragon** · 09-08-2005

Originally Posted by Narf

Why? I don't know about you, but I'm not perfect. I forget to include stdlib.h all the time, and I'm also aware of legitimate problems that can occur if there's no prototype in scope for malloc. But if that doesn't do it for you, how about less typing, easier maintenance, and cleaner code? There are good arguments for both sides, but I think in general the arguments to not cast make more sense.

The excuse about stdlib.h is just plain silly. The same can be said about forgetting to include any other header file. In that case why typecast anything if you are that parinoid about forgetting to include one or more header files? The argument about whether to typecast malloc or not to typecast malloc can be made about typcasting any function that returns a void pointer.

Originally Posted by Narf

Because a lot of people--like you--take what I say and mangle it to the most extreme possible interpretation.

I just took what you said and streatched it a bit (well, maybe a lot) to illustrate a point. Some posters here appears to be very parinoid about typcasting. And parinoid for the wrong reason(s). I'm not saying anyone has to typcast, but (s)he cannot be critized for doing so. Of course, in the academic world students must comply with the coding standards set by the instructor(s), and in the real world programmers must comply with the company's coding standards (hopefully they have them!).

This is my last post on the topic. Good discussion that did not digress into namecalling like one of the other recent threads

**Narf** · 09-08-2005

Good discussion that did not digress into namecalling like one of the other recent threads

I will never resort to namecalling. And you shouldn't cut a stimulating debate short because you're afraid of that.

The same can be said about forgetting to include any other header file.

Yes. Yes it can. But the problem still exists whether you're talking about malloc() or do_my_foo() in slaphappy.h. I think you're missing my point. I don't typecast at first so that I can weed out common errors like forgetting a header. Then I add casts as needed to get a clean compile. Why waste time looking for bugs when the compiler can do the work for you? I'm not against casting by any stretch of the imagination, and I'm often caught casting my malloc(). What I am against is blindly casting--or not casting--without a thought.

Some posters here appears to be very parinoid about typcasting.

Probably the same ones that are paranoid about goto.

Well, I suppose this conversation is over since that was your last post and I can't respond to nothing. Cheers!

**negevy** · 09-08-2005

it was only a simple while()
in the main function.

**Salem** · 09-09-2005

> Some posters here appears to be very parinoid about typcasting.
Well perhaps you've never worked on a project where casting was so endemic as to turn C back into B.

Casting malloc seems like the blind leading the blind to me.
At best it does NOTHING
At worst, it hides a whole bunch of potentially serious errors.
What part of this are you having problems with?

Take a look at C++, look at how it's refining the rules on casting. All too often people just reach for a cast just to make the compiler (or some other tool) just shut the ........ up without actually considering what the real problem is. The more you cast, the more you cripple the system from being able to tell you any useful information.

> The excuse about stdlib.h is just plain silly.
Or any other header file which you might include from your own or any body elses library?
No wait, don't tell me, all your code begins with
#include <*.h>
just to make sure

There is NO way you can make that sort of guarantee, and going round telling people to cast stuff just hides the problems.

**Ancient Dragon** · 09-09-2005

> At worst, it hides a whole bunch of potentially serious errors.

Ok, name them. Just even one "potentially serious error" will typcasting malloc() hide?

Code:

char *ptr = (char *)malloc(sizeof(struct mystruct));

Now what are the potential errors that are hidden in the above code?

Thread: dont konw what to do next.

Thread Tools

Search Thread

Display

dont konw what to do next.

I didnt understand anything

thank u everybody