bug of the day
-
here's one that took me all damn day to fix:
CFont * of = (CFont *)dc.SelectObject(m_font);
if (of)
{
dc.GetTextMetrics(&tm);m_iCharDX = tm.tmAveCharWidth;
m_iCharDY = tm.tmHeight;dc.SelectObject(of);
}if was blowing up on the final SelectObject. can anyone spot the problem ? the answer is in the next post. -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
what MFC really wants you to do is this:
CFont * of = dc.SelectObject(&m_font);
if (of)
{
dc.GetTextMetrics(&tm);
m_iCharDX = tm.tmAveCharWidth;
m_iCharDY = tm.tmHeight;dc.SelectObject(of);
}the only difference is that i'm passing the address of m_font, not m_font itself. also, very interesting is the fact that if i don't select "of" back into the DC in the first example (bad, i know), it doesn't crash and actually works fine. so, for some reason, selecting the object and not it's pointer, returns a bad default object. (&#B^)&$^)#X*&#&^)BPX#E:JSDXHXJSHHKJHDCDJH fucking MFC!!!! :) -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
-
what MFC really wants you to do is this:
CFont * of = dc.SelectObject(&m_font);
if (of)
{
dc.GetTextMetrics(&tm);
m_iCharDX = tm.tmAveCharWidth;
m_iCharDY = tm.tmHeight;dc.SelectObject(of);
}the only difference is that i'm passing the address of m_font, not m_font itself. also, very interesting is the fact that if i don't select "of" back into the DC in the first example (bad, i know), it doesn't crash and actually works fine. so, for some reason, selecting the object and not it's pointer, returns a bad default object. (&#B^)&$^)#X*&#&^)BPX#E:JSDXHXJSHHKJHDCDJH fucking MFC!!!! :) -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
Chris Losinger wrote: (&#B^)&$^)#X*&#&^)BPX#E:JSDXHXJSHHKJHDCDJH f***ing MFC!!!! It's a poor workman who blames his tools ;P At least now I know I'm not the only one who can spend hours staring at the obvious and not see it.
CPUA 0x5041 Sonork 100.11743 Chicken Little "So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies Within you lies the power for good - Use it!
-
here's one that took me all damn day to fix:
CFont * of = (CFont *)dc.SelectObject(m_font);
if (of)
{
dc.GetTextMetrics(&tm);m_iCharDX = tm.tmAveCharWidth;
m_iCharDY = tm.tmHeight;dc.SelectObject(of);
}if was blowing up on the final SelectObject. can anyone spot the problem ? the answer is in the next post. -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
-
Wow, that *is* a sneaky one. I only ran into it once, but probably spent about as long trying to track it down. Believe me, i was cursing MFC and it's "helpful" overloads by the end.
[Shog9]
Shog9 wrote: i was cursing MFC and it's "helpful" overloads by the end. Yeah, they can really lead you up the path. :-) Regardz Colin J Davies
Sonork ID 100.9197:Colin
You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining. Said by Roger Wright about me.
-
here's one that took me all damn day to fix:
CFont * of = (CFont *)dc.SelectObject(m_font);
if (of)
{
dc.GetTextMetrics(&tm);m_iCharDX = tm.tmAveCharWidth;
m_iCharDY = tm.tmHeight;dc.SelectObject(of);
}if was blowing up on the final SelectObject. can anyone spot the problem ? the answer is in the next post. -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
MFC is a bitch, isn't it? The whole idea of C++ wrapper classes around resources that don't provide some reference counting is a bitchy mess gone crazy, and MFC's GDI handling is a reference implementation for that. My bug de jour:
codo Ab0 = Cd + De*f2 ; + parallel(codo(C2), D2*f2);
notice the semicolon? and the compiler doesn't even complain at warning level 4.... having this in some 50+ lines of heavycalculation sure can be deadly. *grrch* [edit] corrected typo ; ) [/edit]
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
-
Chris Losinger wrote: (&#B^)&$^)#X*&#&^)BPX#E:JSDXHXJSHHKJHDCDJH f***ing MFC!!!! It's a poor workman who blames his tools ;P At least now I know I'm not the only one who can spend hours staring at the obvious and not see it.
CPUA 0x5041 Sonork 100.11743 Chicken Little "So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies Within you lies the power for good - Use it!
-
MFC is a bitch, isn't it? The whole idea of C++ wrapper classes around resources that don't provide some reference counting is a bitchy mess gone crazy, and MFC's GDI handling is a reference implementation for that. My bug de jour:
codo Ab0 = Cd + De*f2 ; + parallel(codo(C2), D2*f2);
notice the semicolon? and the compiler doesn't even complain at warning level 4.... having this in some 50+ lines of heavycalculation sure can be deadly. *grrch* [edit] corrected typo ; ) [/edit]
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
peterchen wrote: codo Ab0 = Cd + De*f2 + ; parallel(codo(C2), D2*f2); Just takes it as two differnt lines of code. :~ Regards, Brian Dela :-)
-
PJ Arends wrote: At least now I know I'm not the only one who can spend hours staring at the obvious and not see it. I though that was the whole idea??? Regards, Brian Dela :-)
Brian Delahunty wrote: I though that was the whole idea??? Like I said, some times I just miss the obvious. (or did I just do it again?)
CPUA 0x5041 Sonork 100.11743 Chicken Little "So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies Within you lies the power for good - Use it!
-
MFC is a bitch, isn't it? The whole idea of C++ wrapper classes around resources that don't provide some reference counting is a bitchy mess gone crazy, and MFC's GDI handling is a reference implementation for that. My bug de jour:
codo Ab0 = Cd + De*f2 ; + parallel(codo(C2), D2*f2);
notice the semicolon? and the compiler doesn't even complain at warning level 4.... having this in some 50+ lines of heavycalculation sure can be deadly. *grrch* [edit] corrected typo ; ) [/edit]
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
How is that possible? It's surely a syntax error! If you were another man, I would kill you where you stand! The line must be drawn here! This far, no further! They must pay for what they've done!
-
here's one that took me all damn day to fix:
CFont * of = (CFont *)dc.SelectObject(m_font);
if (of)
{
dc.GetTextMetrics(&tm);m_iCharDX = tm.tmAveCharWidth;
m_iCharDY = tm.tmHeight;dc.SelectObject(of);
}if was blowing up on the final SelectObject. can anyone spot the problem ? the answer is in the next post. -c
Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."
Once you told me it was bombing at
SelectObjectI looked at MSDN to find this link, which shows you need to pass a pointer to the font object. CDC::SelectObject [^] :) Nick Parker
If the automobile had followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year killing everyone inside. -Robert Cringely
-
Once you told me it was bombing at
SelectObjectI looked at MSDN to find this link, which shows you need to pass a pointer to the font object. CDC::SelectObject [^] :) Nick Parker
If the automobile had followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year killing everyone inside. -Robert Cringely
sure, but: MFC provides overrides for things like:
void GetClientRect( LPRECT lpRect ) const. you don't have to pass the address of your CRect, you can just pass your CRect, because MFC provides a conversion (to convert CRect to LPRECT). so, since the code does compile and runs fine (unless you actually use the return from SelectObject), you can blindly assume that MFC is doing something smart in the background. you don't discover the inconsistency until you've wasted 24 hours of debugging time. even worse, the first code runs fine under BoundsChecker, but blows up outside. -c
"Half of the harm that is done in this world is due to people who want to feel important." -- TS Elliot
-
How is that possible? It's surely a syntax error! If you were another man, I would kill you where you stand! The line must be drawn here! This far, no further! They must pay for what they've done!
Awww... the post had a typo (I definitely need vacations), it was
codo Ab0 = Cd + De*f2 ; + parallel(codo(C2), D2*f2);
which simply "separates" the function call as another statement. I would have expected WL 4 to note an "useless side effect" by the + in front of the function, but as a unary plus is indeed useless the compiler probably thought "who cares"
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
-
Brian Delahunty wrote: I though that was the whole idea??? Like I said, some times I just miss the obvious. (or did I just do it again?)
CPUA 0x5041 Sonork 100.11743 Chicken Little "So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies Within you lies the power for good - Use it!
PJ Arends wrote: Like I said, some times I just miss the obvious. (or did I just do it again?) I'm cnfused now :confused: Regards, Brian Dela :-)
