Bone Headed Mistakes
I just spent about 2 hours redesigning a few of my classes.
When I do this type of thing, I usually make most of the chore changes and then let the IDE's intellisense take me to the variables which have been renamed etc, and syntax errors I've made.
Everything was going surprisingly smoothly.
Then I realized that I was modifying the backup instead of what I was compiling.
When I do this type of thing, I usually make most of the chore changes and then let the IDE's intellisense take me to the variables which have been renamed etc, and syntax errors I've made.
Everything was going surprisingly smoothly.
Then I realized that I was modifying the backup instead of what I was compiling.
Last edited on
In a similar vein, I've made made changes to a program's source code to fix a bug or change some behaviour, rerun the program a few times to see if the changes worked, and then realised that I didn't recompile the program. The scariest thing is when the program works anyway, even though the executable is the same (that has actually happened, but it was because it was running in a debugger and the debugger was probably changing some things, like fixing uninitialised variables).
The worst part was that there was a minor bug in what I was compiling, and I was trying to fix it in the backup I wasn't compiling; really had me scratching my head.
That's what made me realize I was modifying the wrong file.
That's what made me realize I was modifying the wrong file.
It's so frustrating when things like that happen. Or, when you're looking at a piece of code that should work perfectly but doesn't, and you can't figure out why, so you rewrite it and it ends up pretty much exactly the same as it was before, but somehow it works, and you can't figure out what you did differently that made it work. Programming can be so annoying at times.
closed account (zb0S216C)
Once before, I tried compiling a program with Direct X libraries. I constantly got unresolved external linker errors with functions that pertained to Direct X libraries. What I didn't realise was that I only included the libraries for the debug build, but not the release build. I spent hours trying to compile the release build. I felt a bit of a tw*t when I had realised what I was doing.
The most embarrassing thing I've ever done was replacing my desktop wallpaper with a screenshot of my desktop, and hid the task bar. I did it to trick my brother. When I logged-on to my PC a few days later, I forgot about the entire desktop thing, and I was frantically trying to get the start button to appear :)P
Wazzak
The most embarrassing thing I've ever done was replacing my desktop wallpaper with a screenshot of my desktop, and hid the task bar. I did it to trick my brother. When I logged-on to my PC a few days later, I forgot about the entire desktop thing, and I was frantically trying to get the start button to appear :)P
Wazzak
That reminds me of something I used to do at school: get a picture of a BSOD, paste it into PowerPoint, and then hit F5 to view it in fullscreen :P
It actually tricked some people. One day, I tried it at the Apple store (but with a kernel panic screen to make it more believable (even though it was a Linux kernel panic, not an OS X one)) and even the guy who worked there believed it (at least, I think he did).
It actually tricked some people. One day, I tried it at the Apple store (but with a kernel panic screen to make it more believable (even though it was a Linux kernel panic, not an OS X one)) and even the guy who worked there believed it (at least, I think he did).
@chrisname
That's a bit of a flaw in your compiler, if you ask me. If anything, the debugger should be more strict than absolutely necessary. In VC++, the debugger "forces" errors on things like unitialized variables by filling in bogus values, even though the release build will always automatically set uninitialized values to zero.
| ...but it was because it was running in a debugger and the debugger was probably changing some things, like fixing uninitialised variables). |
That's a bit of a flaw in your compiler, if you ask me. If anything, the debugger should be more strict than absolutely necessary. In VC++, the debugger "forces" errors on things like unitialized variables by filling in bogus values, even though the release build will always automatically set uninitialized values to zero.
I don't think the compiler should hide a programmer's mistakes by setting uninitialised variables for you (except for static variables, because the standard says so). It should warn you or produce an error instead. The debugger shouldn't do it either, but they tend to zero that section of memory after loading and before starting the program.
Personally I don't agree with compilers or debuggers hiding my mistakes. I want my mistakes to be as obvious as possible so I can fix them, even if they have no effects. I want all of my code to be my best.
Personally I don't agree with compilers or debuggers hiding my mistakes. I want my mistakes to be as obvious as possible so I can fix them, even if they have no effects. I want all of my code to be my best.
| it was running in a debugger and the debugger was probably changing some things, like fixing uninitialised variables |
The debugger operates after the program has already been compiled and linked. I suspect this is actually down to having separate compiler settings for building with the intention of debugging. The debugger doesn't run around changing uninitialised variables.
Topic archived. No new replies allowed.