Just saw this in some code btw --
// override the foo done in the conbufuctor
int foo(char *buf)
{
}
Just saw this in some code btw --
// override the foo done in the conbufuctor
int foo(char *buf)
{
}
If it hadn't got to the point where the CPU just halts and stops executing instructions, then it was still several degrees away from permanent damage.
I think C# does what C and C++ do (though I don't know for sure and could be wrong):
[code]int[3][3] a = { {1, 2, 3}, {4, 5, 6}, {7, 8, 9} };[/code]
is really the same as:
[code]int[9] a = {1, 2, 3, 4, 5, 6, 7, 8, 9};[/code]
except for the way that you index it using [].
Another reason for "load bearing printfs" is if your stack or heap are messed up (e.g. buffer overrun), but the printf "fixes" it or avoids it with a side effect that seperates the buffer overrun from tthe important stuff you'll use later on...
Hey, you just need to change the storage to a filesystem with automatic compression. I bet if it was the right algorithm or configured right, the compression/decompression time would be worth trading for the massive amount of swap space used.
Don't assume that a pointer is 4 bytes!
the first 4 bytes of this T is overwritten with a pointer
I actually did distinguish between local and non-local members. Public members start in upper case (just a habit from C# I suppose)...
You should overload an operator
* A when it makes complete sense, to say, have one object less than another
* You must (e.g. to use an object in an STL container that sorts, like std::set)
Just overloading an operator to be slick or cool is going to end up causing some confusion
@yellowdog said:
I remember when I was in college, in one of my more bacis progamming classes (maybe COBOL, not sue) but it said that if you were going to use an If/Else (especially if you had more than one else) to put the item that will happen (or be true) the majority of the time at the top (the first if). This way the code has to process less to get the answer.
I agree. You get into double-, tripple-, quadruple negatives!
Try reading the code out loud. Is it clear?
1.if(HidePanel != false) { do stuff; } else { do other stuff; }
"If hide panel does not equal false, then do stuff, else do other stuff."
2.if(HidePanel) { do stuff; } else { do other stuff; }
"If hide panel, then do stuff, else do other stuff."
3.if(ShowPanel) { do stuff; } else { do other stuff; }
"If show panel, then do stuff, else do other stuff."
To me, (2) and (3) are the same. The only difference would be whichever is the more "interesting" state, show or hide.