for (i = 0; i < foo; ++i)
{
for (j = 0; j < bar; ++i)
{
}
}
Luckly I have done this enough that I have gotten pretty good at finding it.
Dumbest coding mistakes ever
Luckly I have done this enough that I have gotten pretty good at finding it.
Just wrote this. Luckily it got caught as a warning, otherwise it'd have been really annoying. Just so you know, [font=courier new,courier,monospace]name[/font] is a const char*.
Why is ++ allowed on a const value? I'd like to say that maybe it's because the return value is modified, but it's a post-increment (so the original value would be returned) and even then there are other easy ways to approach that (e.g. the + operator). Take into account this is C, not C++, so there isn't any wacky overloading going on (and even then, it's a char...). Moreover, it's being compiled with -std=c99, so extensions are disabled.
(and before you ask, no, I wasn't reinventing strlen, the loop code does more than just counting characters)
for (unsigned len = 0; *name; len++, *name++) {Why is ++ allowed on a const value? I'd like to say that maybe it's because the return value is modified, but it's a post-increment (so the original value would be returned) and even then there are other easy ways to approach that (e.g. the + operator). Take into account this is C, not C++, so there isn't any wacky overloading going on (and even then, it's a char...). Moreover, it's being compiled with -std=c99, so extensions are disabled.
(and before you ask, no, I wasn't reinventing strlen, the loop code does more than just counting characters)
*name++ is *(name++), not (*name)++
Derp, and the most ironic is that I had remembered that syntax specifically (since it matches one of 68000's addressing modes). I wonder what was I thinking when I wrote that post.
C#: I was hunting down a bug, so went in and set a conditional breakpoint deep in the bowels of this data access code
And then went to lunch. Came back and bug was still there, but the breakpoint wasn't hit. Rebuilt, redeployed and still a bug. Nobody else got the bug though, and it worked fine in release mode. Step throught the code... data model entity goes into the translator, view model comes out with the wrong location...
Took me 2 days to find the conditional breakpoint which will do the assignment, and will never actually trigger since assignment isn't "true".
entity.Location = "http://....somebiglongstring.html"
And then went to lunch. Came back and bug was still there, but the breakpoint wasn't hit. Rebuilt, redeployed and still a bug. Nobody else got the bug though, and it worked fine in release mode. Step throught the code... data model entity goes into the translator, view model comes out with the wrong location...
Took me 2 days to find the conditional breakpoint which will do the assignment, and will never actually trigger since assignment isn't "true".
uint16 numVerts = 0;
for(size_t i = 0; i<70000; i++)
numVerts++;
Twice last week
Here's another really fun one:
for ( size_t i = 0 ; i < v.size() - 1 ; ++i )
{
...
}
I acknowledge I'm a bad C++ programmer, but what exactly was the problem with those pieces of code. They both will compile and run. Won't they?
I acknowledge I'm a bad C++ programmer, but what exactly was the problem with those pieces of code. They both will compile and run. Won't they?
The first one is just a waste of time - he might as well have set numVerts directly.
The second will fail horribly if v.size() == 0.
The second will fail horribly if v.size() == 0.
Why would it fail? Wouldn't it just do nothing? Or is it because v.size()-1 presumably is unsigned since it's being compared against a size_t so it would run MAX_INT times?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
