Clever Code

So you compare a string with a bool - doesn't that cause an implicit conversion? It's long ago that I used PHP, but it might be strange enough to convert every non-empty string to true (instead of the more obvious conversion: converting the bool to string). I remember something about the === operator for comparisons with true/false as error codes to prevent implicit conversions, switch probably only uses ==. Also, you forgot the ':' after case 'email'.

Chris Losinger wrote: one is illegal in C# and one generates a warning Yes... but in my intentions this is an excessive synthesis: The two facts are: "one is illegal and the other not" (in the language spec. scope) "one gets and error and the other a warning" (in the compiler implementor scope) I can easilly think to a compiler not generating such warning and respecting the spec. Of course this becomes the same if you're using one and only compiler for a given language. To come back to the origin, my point is: this is not a subtle bug, since it doesn't descend from a compiler bug, library bug, documentation misinterpretetion or ambiguty etc. It's just a regular (not subtle) programmer bug, originating from a wrong statement in a wrong place. 2 bugs found. > recompile ... 65534 bugs found. :doh:

BrianShields wrote: I only ever saw the compiler bug you linked once and it was in a pretty munged loop (nested STL adaptors, Managed code), I'm surprised something so simple could reproduce it. Actually, the SSCCE for the loop optimization bug was pretty short itself: // Using VS .NET 2003, when compiling without /O2, output is: // before: abcd after: cdxx // but compiling with /O2, output is: // before: abcd after: cxxx // // This seems to be fixed with VS .NET 2003 SP1 #include <iostream> int main() { char c[4]; c[0] = 'a'; c[1] = 'b'; c[2] = 'c'; c[3] = 'd'; std::cout << "before: " << c\[0\] << c\[1\] << c\[2\] << c\[3\] << " "; for (int n = 2; n > 0; --n) { for (int i = 0; i < 3; i++) { c\[i\] = c\[i+1\]; } c\[3\] = 'x'; } std::cout << "after: " << c\[0\] << c\[1\] << c\[2\] << c\[3\] << std::endl; return 0; } BrianShields wrote: Have you utterly verified that index 0 in that case was true in Release as well? Yes, if I comment out the original loop and display the contents of the array in a MessageBox, indeed the first element is true. It was retrieving the same data from the DB as in Debug mode anyway. -- Marcus Kwok

Try to put the Byte array into a MemoryStream first. I had the same problem. I also found that Adobe is a crap product in general. Try checking to see if a message box appears behind your Web Application. Sometimes the application hangs up waiting for you to address a message box hiden behind your app. I might be able to dig up my original sample but now it is late for me I must go. nothing

So? -------- Micrologic Networks, India

That is nasty! Even though documentation says it isd a macro, this is a side effect that I think should be documented. (I shunned away from these macros most of my time anyway, now more incentive to do soo...) I wonder: would the following definition would help: #define ListView_SetItemText(hwndLV, i, iSubItem_, pszText_) \ { LV_ITEM _ms_lvi;\ _ms_lvi.iSubItem = iSubItem_;\ (_ms_lvi.pszText = pszText_,\ SNDMSG((hwndLV), LVM_SETITEMTEXT, (WPARAM)(i), (LPARAM)(LV_ITEM *)&_ms_lvi));\ } Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers! We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP Linkify!|Fold With Us!

Probably depends on how strict your compiler is! Just mentioning the name was probably sufficient for some pre-standard and less-conformant compilers, but the standard says to use using. Stability. What an interesting concept. -- Chris Maunder

looks like it's related to something i posted here a while back. -c image processing toolkits | batch image processing | blogging

NoCake wrote: If I can define a colour as 4 bytes rather than 4 ints, then the colour fits nicely into a 32bit register, I can work on an large array of colours with x4 fewer cache hits, and it'll save bus bandwidth if I transfer that colour data to, say, a graphics card. However, depending on the system you are using, reads and writes might be slower depending on the system's alignment requirements. For example, you may be able to store four 8-bit bytes in one 32-bit word, but if the system can only read whole words at a time, then each access would need extra instructions to mask and shift the word, possibly slowing down the code. But as you said, the cache effects could outweigh these extra steps. So, it's very difficult to predict with a high degree of accuracy what will happen. The moral of the story is that you need to profile to make sure what you're doing has the effect that you want. -- Marcus Kwok

Well, that might have been true with VS 6.0, where STL was abyssal. But since 2003 and definitely since 2005 STL and the compilers template implementation is one of the best (not the best, mind you, but ahead of most of the competition). Magnus

You should see the protocol I've got to work with :mad:, makes yours sound very nice to work with. I have no idea what I just said but my intentions were sincere. Poore Design

Hmm...that sounds like there ius a bug in the network layer - specifically the io completion/io cancel routines as such is OS/network card driver specific so would assume that it would work fine on anything else. Hmmm looks like Vista is bleeding edge:(

The 24 day hint was the clue for me. 3 to 4 minutes to the correct solution. And I found another VERY rare bug. Bug found by finding the number of milliseconds in 24 days. This was about half of 2^32. Thus DWORD had to be signed which produced a negative number after 0x7FFFFFFF milliseconds. The second bug is in your GetUpTime() function. About every 48 days the low counter overflows into the high word. If you catch the high word before the overflow and the low word just after the overflow you will have a problem. Fix: read the high word a second time. If unchanged you are done otherwise loop back and read both again. The second time the high word will match. (If counters take much processing to read then range check the low word. If (unsigned) less than 1000 – one second – then check the high word again. Otherwise it should be safe to skip the high word check.) The method given above works well in 8-bit microcontrollers for reading 16-bit counters on the fly without requiring h/w interlocks.

:laugh: I did that on the first pass through a quick addon to some automated test cases. These particular test cases were dealing in core areas of my design, and were dealing with carefully constructed test data sets, and I figured it's be nifty to also throw in some data about time spent in the test case. My first reaction to the times were Holy crap that's fast! I rule!. Then it hit me that the test case which apparently took just under 200 milliseconds was accessing an amount of data from disk that simply could not be read from disk in that timeframe, let alone fully processed. I ran it a few more times, and then it dawned on me :)

Btw, this is the wrong forum for questions - This is a forum for people to post about bugs they've experienced and fixed

I agree, this forum looks like it is going to be a lot of fun provided everyone states the problem (entertainment) and then provides the solution. I’ve taken the word 'impossible' out of my vocabulary, because it does not apply to software bugs.

I am impressed and am very glad that it was not me that had to solve that problem. You can only beat you head against a wall so many times before you get a head ache. INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra

The value-of pA->myType is the value-of pA->A::myType which has not been initialized. Some changes: class A {public: A(){/*myType = TYPEA;*/} ~A(){} TClassType myType;}; class B : public A {public: B(){ myType = TYPEB; } ~B(){} TClassType myType;}; class C : public A {public: C(){ myType = TYPEC; } ~C(){} int myType;}; A* pA; B* pB; C* pC; pA = myArray.GetAt(0); //LINE A pA = myArray.GetAt(1); //LINE B pB = (B*)pA; TClassType eAB = pB->myType; TClassType eAA = pB->A::myType; pA = myArray.GetAt(2); //LINE C pC = (C*)pA; TClassType eAC = TClassType)pC->myType; eAA = pC->A::myType; Results: TYPEB == pB->myType // B::myType 2 == pC->myType // C::myType, 2==TYPEC ? == pA->myType // A::myType when uninitialized TYPEA == pA->myType // A::myType when initializion is uncommented Comments: Data-members are hidden or overridden. "Plain" function-members are hidden or overridden. Virtual function-members are virtual (behavior you expected). Hiding/overriding depends on NAME not type (see TClassType versus int). More comments: Such hiding is probably most often not done on purpose. Therefore Hiding data-members is 99.9999% (sure to result in) a bug. Hiding function-members is 99% a bug.