Ever had an issue you just couldn't debug? You tried stepping through the program and the relevant parts line by line and the values in your watch window look ok, but the magic just isn't happening when you hit 'run'. You spend hours these problems, and then when you relax and take a bath or a walk the Archimedes moment happens and you realise the small mistake you made.

As for me I was trying to implement interleaved array buffer objects in Open GL today, and the meshes were rendering but the texturing just wasn't happening. After some careful deliberation and many attempts over a few hours, I gave up. When I was walking to my local restaurant I realised I didn't call glEnableVertexAttribute(). I get home, try it and it runs!

So, time wasted or a lesson well learned?

What are your most frustrating problems that were solved with something simple you forgot?

Cant recall anything very interesting, but the latest ones were forgetting to make a function return a reference instead of a value (and assuming assigning an object to a reference would change where the reference points) and trying to figure out why my game always renders the cells in the middle of the screen as "loaded" (with chunked terrain) instead of the ones at the origin, because i forgot that of course the chunks will be loaded around where you are looking and not around the origin xP

lol yes, I remember a few times actually where I wanted something to happen, and it didn't. Spent a while trying to debug it, and it was as simple as calling the method.

Pass-by-reference can be a killer:

• Neglecting to pass an argument by reference, and then staring at a profile trace where 75% of the time was spent in a copy constructor.
• Passing by reference the nodes in a recursive-descent parser, which caused the same instance to be modified over and over again, and the parse to get stuck in loops.

This took me back about 4 years, when I was working on my capstone uni project. Me and a friend were getting linker errors - something along the lines of " somevariable already defined in somefile.obj". No compilation errors - all our headers were #ifndef guarded, so we were scratching our heads for near four days.

The obvious thing, in retrospect, is that #ifndef guards only stop code declaration from happening twice. If you (as we did) put actual data in a header file (say, something like int someCount; that is not static), it doesn't matter if the .h file is guarded, when its included multiple times the linker will try allocate the variable again, and will fail, giving an error like above.

Bottom line is don't put anything except declarations in your header.

Best one I've seen is a program missing the '()' when calling glEnd. Caused BSOD! Took a while to figure out till we realized we overlooked something as simple as some brackets haha.

1. Template meta-programming. 'nuff said.
2. Deciding to do a small project in C, and forgetting all locals must be declared *before* any code statements in a scope.
3. I once was doing some pointer arithmetic in Quickbasic, and my program, a 16bit DOS app, would crash windows entirely. I narrowed the problem down to one of four identical lines. It turns out that in one of those lines, in one place, I multiplied the pointer by some value, rather than adding. I have no idea what that caused it to overwrite, but I take crashing windows from a supposedly-isolated DOS app to be a point of pride.

Colleagues who think that writing their own custom C++ string classes rather than using a well tested library is wise.

Missing or misplaced commas and brackets - I have spent half days utterly confused by these stupid mistakes that I made, every coder no matter how experienced has done this at some point.

This:

>>>import time
>>> def report(when=time.time()):
...     print when
...
>>> report()
1210294387.19
>>> time.sleep(5)
>>> report()
1210294387.19

Python default arguments are defined when the function is defined, not when it's called. Calling report will always return the same value with no arguments. (I took this specific example from stackoverflow, but it's bitten me a few times).

Or you can get caught by it this way:

A contrived in Oracle SQL:

SELECT * FROM table WHERE null != null

Will always return zero results because null is never equal or inequal to anything. In Oracle, varchar fields are never empty. They either have something in them, or they are null. Zero-length strings are considered null.

This means that the query:

SELECT * FROM TABLE WHERE COLUMN1 != 'THIS'

Will not return any rows where COLUMN1 is empty. The natural expectation would be that when COLUMN1 has no value, then it would not be equal to 'THIS' and thus would be included in the resultset. At least that seems natural to me.

The workaround:

SELECT * FROM TABLE WHERE COLUMN1 IS NULL OR COLUMN1 != 'THIS'
-- OR YOU COULD DO
SELECT * FROM TABLE WHERE NVL(COLUMN1, 'SOME-IMPOSSIBLE-VALUE') != 'THIS'

Last month I needed to access single characters from Delphi Strings. But whatever I did my program just put out trash and crashed.

After six hours (and almost implementing a replacement system) I got it:

While arrays start by zero, Strings in Delphi start at 1. So i kept interpreting the first byte, which does totally mess up Unicode....

Additionally in another project (GCC/Linux => C++) there was a function, log(), which compiled properly, but the linker never found it, whatever I try. (Multiple Headers, directly in the source file etc). Hours later I finally found an answer: The function was declared as

inline void Log( Ogre::String MSG );

In VC++ this works fine, but under GCC/Linux the "inline" caused the linker to search the function without finding it. Wasted way too much hours searching mistakes like that...