dont konw what to do next.

This is a discussion on dont konw what to do next. within the C Programming forums, part of the General Programming Boards category; Im doing the tower of hanoi but without recursion. Im trying to do it with linked list. I have managed ...

  1. #1
    Registered User
    Join Date
    Aug 2005
    Posts
    9

    dont konw what to do next.

    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;
    	
    	
    	
    	
    	
    	
    }

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,659
    > 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...
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    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.

  4. #4
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    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.
    Hope is the first step on the road to disappointment.

  5. #5
    Registered User
    Join Date
    Aug 2005
    Posts
    9

    I didnt understand anything

    so what do I have to do next?

  6. #6
    Registered User
    Join Date
    Oct 2001
    Posts
    2,934
    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."

  7. #7
    Nonconformist Narf's Avatar
    Join Date
    Aug 2005
    Posts
    174
    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.
    Just because I don't care doesn't mean I don't understand.

  8. #8
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    Quote 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.

  9. #9
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,659
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  10. #10
    Nonconformist Narf's Avatar
    Join Date
    Aug 2005
    Posts
    174
    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?
    Just because I don't care doesn't mean I don't understand.

  11. #11
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    Quote 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.

    Quote 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

  12. #12
    Nonconformist Narf's Avatar
    Join Date
    Aug 2005
    Posts
    174
    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!
    Just because I don't care doesn't mean I don't understand.

  13. #13
    Registered User
    Join Date
    Aug 2005
    Posts
    9

    thank u everybody

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

  14. #14
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,659
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  15. #15
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    > 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?

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21