![]() |
|
#1
|
|||
|
|||
Linked list: differing results on same code.hi again,
Someone from the list sent me a linked list example they had made. When I compile/run the output shows a problem. When he runs it it doesn't. Even when I run the same .exe as he And vise versa! I am win98/mingw gnu c (or dmc) , , He is XP devc++... I hate to bother the list but we are baffled and wondered if someone might kindly offer some reason for this anomaly. Here is the exact code we both are using: (hope I don't get kicked off for all this) CPP / C++ / C Code:
Code:
Thanks, Howard... Last edited by admin : 26-Jun-2007 at 21:32.
Reason: Use [code] tags for output examples
|
|
#2
|
|||
|
|||
Re: Linked list: differing results on same code.Quote:
You didn't show output for the other guy's program on the other computer. What did it look like? You didn't actually tell us what the problem is. I see a problem with the sort routine, and since you printed out everything, I think you can probably see what causes it. Maybe the question should be, "Why would it appear to sort the list correctly on the other machine even though there is a bug?" If so, then my answer is: have you looked at the output on the other machine (with everything printed out the way you showed here)? When programs act differently on different systems it is often due to different things that the compilers/loaders/linkers do with uninitialized variables. For example, if your sort routine has a bug that somehow uses the value member of a struct that hasn't been initialized, sometimes it might move up in the list, depending on whether running the code resulted in a value smaller than the numbers you entered into your list or larger. Some compilers are "neat freaks" and create code that puts zero into uninitialized variables, even though the language standards for C and C++ say that the values are undefined. Others just leave seemingly "random" garbage---which may or not be "random" at all, but often results in very large integer values for example. Try changing the insert function to something like: CPP / C++ / C Code:
I'll insert a couple of small numbers and see what happens with the sort: Code:
Now, change #if 0 to #if 1 Code:
Remember that in the (bugous) code that you posted, the last value wasn't defined, so the results might be different on different machines. (This shouldn't have been used in comparisons for sorting, anyhow, right? That's the bug.) Now, have the other guy make the same changes in the program on the other system and see what happens. Regards, Dave Footnote: the bug is not that you didn't initialize the value. The bug is that the sort routine erroneously used it in a comparison that brought it into play. The last item in the list is a dummy (a wasted node whose purpose is only to hold the NULL pointer to indicate the end of the list). The value in that item is irrelevant, but the program, somehow used it. This is an example that shows you can't "prove" a program is correct by testing. Of course you should test your program as thoroughly as you can, but it may just "happen" that some undefined behavior in the program gives apparently good results for your test cases, but in fact a bug exists, and the bug will manifest itself under different conditions. |
|
#3
|
|||
|
|||
Re: Linked list: differing results on same code.As a side note I would like to comment that I don't see a reason for using a "dummy" node as the last node. I mean why waste resources ? Also the first node, the one created by:
CPP / C++ / C Code:
Naturally making use of "head->value" means that the function declarations have to be changed something like: CPP / C++ / C Code:
|
|
#4
|
|||
|
|||
Re: Linked list: differing results on same code.Yes after reading all this i realized my first use of a dummy struct was useless and could be replaced simply by a pointer to the struct.
Here is the new and updated code, although i haven't yet changed the code for the sorting and the deleting the input and output work nice and clean and should solve the problem as soon as i adapt the old functions to it. CPP / C++ / C Code:
|
|
#5
|
||||
|
||||
Re: Linked list: differing results on same code.Good , so yer not upset at yet another monster from moi. ? . ?
So it turns into an Interesting discussion after all. I'm wondering now : Quote:
would that mean the OS is 'filling in the blanks' ? Would that vary according to certain ifndef sorts of specifications? (I don't know much about that yet) Quote:
Quote:
Quote:
Actually, I had a few ?marks about the head declaration and moving head->next_item->next_item->next_item was really causing a brain lockup on my end. I would think pointing a couple of local pointers might be more clear, but really what do I know? So I guess I'm saying I saw a lot of things that looked like they may cause the problem, but my attention was drawn more to the head declaration not being a pointer. The sort blew me away.... I'm glad to see Shalombi's right on a re-write. It will be interesting see what he does differently. Like seprich said, there certainly is many number of ways doing it! (skin a cat) Thanks guys, Howard; |
|
#6
|
|||
|
|||
Re: Linked list: differing results on same code.Quote:
When you get the "minor" problem of running through the list without going too far, you might notice that, generally speaking, you can't perform a bubble sort with one trip (or maybe you noticed it already). If I clean things up a little, and only print the values, the existing bubble sort makes it look like the following. I have entered values 4, 3, 2, 1 into the list (these operations not shown here). Then I print the list and apply the bubble sort function. It needs several passes to get it sorted. Code:
Go back and look at bubble sorts that you did with arrays. Didn't you always have nested loops? By the way, I hate the menu choices. After all, why not use something like 'i' for insert, 'p' for print, 's' for sort, 'd' for delete, etc. It's never too early to consider human engineering. Regards, Dave Footnote: back in the days when the microprocessor world was young (and although I wasn't actually young, I was younger), I worked on a system that had two text editors (line editors actually). These were run from a "dumb terminal" so there was no on-screen menu. No drop-down menu, no right-click context menu (no mouse to click, anyhow), no nothing. All commands were entered from the keyboard. One editor had a command 'k' for "Keep", meaning "keep everything in the current text buffer by storing the current text buffer in a file." The other editor had a command 'k' for "Kill", meaning "erase everything in the current text buffer and start all over again." Imagine how much fun it was erasing all of the work of your editing session by accidentally telling it to "kill" it when you meant to "keep" it. Last edited by davekw7x : 27-Jun-2007 at 11:20.
|
|
#7
|
|||
|
|||
Re: Linked list: differing results on same code.I know very well how to implement a bubble sort, but since this was about linked lists i saw no need of putting the extra loop, the swap function is what i wanted to look at.
The new linked list is much simpler, i will post the new one soon, it will make for a nice example. |
|
#8
|
|||
|
|||
Re: Linked list: differing results on same code.Quote:
Actually, I was responding to Howard's post (notice the "Quote:Originally Posted by howard_L") to mention that, above and beyond the problem of going too far in the sort function, it didn't really sort the list. He didn't actually tell me whether that was the error he referred to in the first post of this thread or it was the creeping zero from the last node. (And I did point out the fact that he never actually articulated the error that was so puzzling.) I didn't mean to talk down to anyone; I just know (from personal experience) that I can get so involved in correcting a technical detail that I sometimes forget what the whole point was. Result is a clean, elegant, beautifully implemented program that doesn't meet the Program Specification. Regards, Dave |
|
#9
|
|||
|
|||
Re: Linked list: differing results on same code.Ok... guess I should have done this from the git-go.
I thought the 'picture' (output) showed the problem better than I could explain and I felt like the post was imposing enough as it was and it was late. My Original Question (/error/problem/anomaly) , by Howard_L: I originally ran the program the way I recieved it: It did NOT print the additional line showing what was in head after loop finished. CPP / C++ / C Code:
- After one sort the line with the largest value in the list would disappear and . . a line with a 'value' of '0' would appear on the last line. - Further sorts would work correctly, moving the '0' to the top... - ... OK - That was my first head scratcher.... So I placed the extra printf()'s in print() to try to find out what was going on: CPP / C++ / C Code:
. . The largest value would go to the head. . . This is where I started to get bogged in confusion about whether head 'was' and . . Whether head 'should be' holding a struct or just a pointer and, and, and, (I still am). - Then I noticed how adding another item and then sorting would actually relace . . the last 'add' with a '0' - ok, so I guess I did think the sort might be a problem, but would it be different if head . . were a pointer rather than a struct... I didn't know.... So that provided some things to think about. I told Shalombi what I was getting. He told me he was NOT getting that and voila! The second head scratcher! Now, If we both got the same problem I guess we would have addressed that, but getting different results EVEN with the same .exe???? I asked if it would be ok with him to call in the big guns... and so ... here I'm is. Confusing everyone with my descriptions. (or lack thereof) Does that describe it (or not) well (or not) enough? Hope that helps (really), sorry to all I have harmed , Howard; |
|
#10
|
||||
|
||||
Re: Linked list: differing results on same code.Quote:
Furthermore, perhaps other people would have liked to help (and could have helped with fewer words and less soap-boxing than me), but couldn't be bothered to figure out what the program was supposed to do in the first place---and what it was not doing to your satisfaction---while wading through the output that you showed and referencing it back to the program. (And then looking for tell-tale uninitialized variables that could be causing inconsistent behavior.) Quote:
Quote:
Quote:
You forgot to put the smiley, since you are obviously kidding. (On the other hand, I rarely if ever put smileys anywhere. You can always tell when I am kidding by noticing the twinkle in my eye and by the tone of my voice.) I, for one, do not regret the thread, since I learned something (about the same .exe giving different results on different versions of operating system, apparently due to the way uninitialized variables are loaded). That makes it a good day for me. (Not because I deliberately use uninitialized variables in my programs, but because I spend some fair amount of time explaining to people why their programs are "wrong" even though the programs seem to be giving the "right" answer.) A little syllogism appropriate to the occasion:
Regards, Dave "We can face our problem. We can arrange such facts as we have with order and method." Hercule Poirot --- in Murder on the Orient Express |
Recent GIDBlog
Observations of Iraq by crystalattice
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| [Include] Doubly-linked List | dsmith | C Programming Language | 6 | 14-Apr-2006 13:12 |
| Help in C Print is not working with LinkList | batman3280 | C Programming Language | 3 | 09-Mar-2006 19:03 |
| linked list error message | Krandygrl00 | C++ Forum | 4 | 22-Jun-2005 14:13 |
| search linked list | itsmecathys | C++ Forum | 20 | 18-Apr-2005 01:34 |
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The