Quote:Original post by iMalc
e.g. Try it without the do while(0), or also without the {}, inside multiple levels of if-else statements. You'll find that there will be special cases where you have to leave off the semicolon for example, to get it to work right where you otherwise would just write it normally.
A fast Google gives lots of hideously ugly code examples. My personal convention is to always have such macros take care of their own semicolons when needed, and no stand-alone macro is ever terminated by a semicolon in code. I find this much easier to read, which is probably why I've never had to bother with a do {} while(0) wrapper. Personal preference I guess.
Quote:Original post by iMalc
Dubbing in relase mode is infinitely easier if you turn optimisations off too etc, so what's your point? If you gotta do it, you gotta do it.
The whole point is that you will have picked up any errors of this kind in debug build before you switch to release build. You should have no remaining assert failures and have tested each execution path in doing code coverage. Sure, problems can appear only in release or only in debug, but it shouldn't be this kind of bug as you would have eliminated them already.
Your utopian concept of all bugs being corrected in debug builds is nice and lovely. I, however, live and code in the real world. If a customer calls and complains that his software just crashed with a pointer exception at 0xBAADF00D I know instantly what is wrong - my code, accessing released memory. I can find and correct the problem often with only a short time of investigation. On the other hand, if they report some random memory address, I have a lot more work to do. If the bug only manifests itself in certain compiler setups, debugging can be a total nightmare. Turning off optimizations and/or returning to debug builds is, in a lot of cases I work with, not an option.
Quote:Original post by iMalc
So why do they turn off clearing blocks to 0xCCCCCCCC for example, in release build then? It's because you've found and fixed any bugs that it would help you find. If a bug of that nature is still present in your release build, clearing the pointer after use certainly isn't going to make your exe run any better, so why bother? The overall increase in speed and decrease in exe size might be small, but some people like it.
I doubt it. The real reason is far more likely related to performance. If I deallocate a 300KB slab of memory, setting every word to some "cleared" value is performance intensive and likely wasted. Of course you could do something like only clear allocated memory blocks of less than a certain size, but this becomes questionable and somewhat unreliable behavior for developers to work with.
Again, I wish your youthful dream of having all bugs fixed in release software were true, but I have to live with real life instead. More's the pity, because it's a very warm, fuzzy dream [wink] Of course clearing the pointer won't make execution any more stable, but it will make the job easier for developers to come back to and fix as needed.
Really the issue for me isn't the specific case of not clearing pointers when deallocated. The issue that I see here is a programmer who doesn't appreciate the benefits of designing code that is easy to debug and maintain in any scenario. It's not the specific example here, it's the underlying mentality.
