If you posted the code and the unexpected result, I’d hazard a guess you might run into one or two people on this site somewhat familiar with code who might be able to take some sort of guess at what might have happened.
But that’s just my opinion, I could be wrong;)
[sub]As long as it isn’t a homework problem or something…[/sub]
I feel your pain; this happens to me every once in a while.
The best one I saw was in a Delphi (not my choice, don’t ask) application - the thing I had (until then) totally failed to grasp with Delphi is that after executing the Form.Close method, the form is just hidden from view - it isn’t unloaded and it can still execute event code.
For example, if you have a data bound control with an OnChange event, moving the record pointer in another form causes the data to change in the (invisible) bound control - executing the code in a form you thought wasn’t even part of the picture.
Then post the minimum compilable piece of code that demonstrates the underlying problem.
(Damn, I’m back in comp.lang.c. I guess the moral is that techies don’t commiserate, they troubleshoot.)
My story is hair-ripping as well. I was doing some work in x86 assembly and using the misdesigned div opcode. (No, not the botched fdiv, this was completely integer work.) The x86 div opcode, instead of simply diving one register by another and putting the result in a third like all sane ISAs do, divides the edx:eax register pair by the single operand, and then puts the quotient in eax and the remainder in edx. This implies that edx, a completely unrelated register as far as the current computation is concerned, must contain data that can be validly used as an extension of eax.
If it doesn’t, your program will fail. It will fail in mysterious ways that give you no useful diagnostics until you compile a C program and look at what the compiler spits out to do the simple job of dividing two integers.
You cannot imagine how long I looked at that code, trying to piece together what made it crash like a drunken freshman. And x86 assembly is not pretty code.
Intel, AMD, and all of the other clonemakers are chained to a 20-year-old ISA that was a bad idea at the time. I haven’t used either of the 64-bit x86 ISAs, but I rest assured that they can be no worse.
Ughh, I hate designing reports. Especially when you’ve set everything nicely and the client wants another decimal place. GAHHHH :mad:
Anyways, sorry, the code is question comes from a few different modules, plus I’ll have to explain everything, and I really don’t feel like doing that.
Ages and ages ago I was writing a program in C which contained a line something like,
x=x+1;
I put a value watch on x and stepped through the code line by line. When the above line executed, the value of x went from something like 135 to something like 432,367,543,234,765!
The Microsoft support tech I was on the phone with solved the problem by asking me to turn off a “conditional” compile feature and re-compiling the code as a whole. It worked fine after that. The thing that killed me is that the tech said:
Oh that feature never works, but it’s turned on BY DEFAULT!
