Greetings, On Wednesday, November 21, 2001 4:38:28 PM you wrote: > I initially thought that there were no differences between the two > cases. However, when I first broached this subject to several > programmers asking them why the heck the compiler tells me the mud > crashes at this very spot all the time, their first reply was to > separate the OR statement. Martijn's explanation sounds plausible, > although I dont understand why MSVC++ does not opt for "lazy evaluation" > as its default. > The debugger actually says something like:- > (+) str: 0xCC00000 "" > value cannot be determined > So, I am guessing that the pointer has a NULL string and yet for some > strange reason, it is trying to evaluate *str (I am also guessing that > the memory address is really just part of the freestack) and hence, it > crashes since *str is invalid. MSVC++ does indeed use lazy evaluation - I cannot think of many compilers that do not, particularly as it is required by the C++ standard, but also the C standard that evaluation is lazy. Makes the language constructs a bit more interesting to manipulate, but that's another story. :o) Now, I'll wager that you are using MSVC++ to do a debug build of your source and this will result in some unexpected behaviour if you do not know of it. The debug heap functions in vc++ is managed radically different than debug heap in most other compilers (forcing you to actually write the stuff "correctly"). Let's ponder a C++ example for a while (works the same way for C allocations). int* ptr; ptr = new int(37); delete ptr; Now, you might think that ptr is 0x00000000 per default, but the debug heap initialises it to 0xcdcdcdcd (some strange bogus value like this). The call to new, however, makes it point to a valid place in memory where we have stored the number 37. After the call to delete however, it has been changed to 0xdddddddd (your milage may vary). Now, if you try to dereference this pointer your program will... crash, yes. :o) Because 0xdddddddd is an invalid address. So now I hear you linux people *mutter* Microsoft can never do anything right */mutter*. However, this is a benefit in most cases when you are doing actual debugging, because you do not want in all cases to set your pointer to 0 when you deallocate the contents it points to - examples are irrelevant to why your mud is crashing, but you can investigate Microsoft Developers Journal or the MSDN magazines if this stuff interests you and how it aids in your debugging - a particularly nice section in one of their magazines is called BugSlayer and works with debugging in many different ways written one of the gurus in the field. Ok, with this in mind, insert a breakpoint at the mentioned line (f9) and hit f5 to run a debug run. Now, each time it hits that line investigate str in the quick debug window and see whether it is actually 0x00000000 or whatever string you are currently expecting. So, unless the corruption took place in some other place you commented out while poking for the bug, I cannot explain why it is crashing. There is no difference between the two statements in how they are executed, so I find it highly improbable that that should be the cause of your crashes. Of course, eventually you want to remember to clean out all the object-files and do a clean rebuild - just in case. :o) And do remember to set up your precompiled headers correctly. (Read: If you have no clue about what they do, disable them!). --- Offnote to the latest arrivals in the thread that came in while I was writing by Martijn Schoemaker: >>Well, we're talking MSVC++ here ... if gcc does not work, I start >>worrying, if MSVC++ does not work, I silently shake my head ;) Compiler are a religious question. GNU insist they read the standard right about how to handle templates, Microsoft disagrees, Borland went the safe way and did both cases... Are any of them wrong? Is VC++ better than g++ or bc++ or vice versa? Hardly likely. The best compiler is the one you are most versatile in using and the one that gives you the best possibilities for solving your problems and debugging. And in my opinion debugging in particular, as that is one of the most problematic areas about programming - most people just don't get it right the first time unless they are copying the source for hello world and even then the majority of tries goes wrong. :o) So really, pointless matter to bring up in a thread pertaining to a bug. :o) -- Yours truly, Henrik Stuart (http://www.unprompted.com/hstuart/) -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST