Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I especially like the claims of "every time we added debug code, the bug 
>> went away". Surely it is impossible to work under such conditions...
> 
>   That was a relatively common problem in C and C++ years ago, but nowadays
> especially C++ compilers have got much better at debugging such things. For
> example Visual C++, when compiling in debug mode, will add bounds checks to
> all STL code and IIRC raw array accesses (although there are limits to the
> latter, as it's quite difficult to check bounds when pointer arithmetic is
> being performed). gcc has a precompiler constant which, when defined, turns
> on similar checks to all STL code. Then you can use valgrind to catch the
> rest.
> 
>   The only situation nowadays where you might end up having such heisenbugs
> in C++ which are not caught by the compiler even in debug mode is if you
> use dirty raw pointer arithmetic hacks, which is something you seldom really
> have to do in clean good-quality code, not even if you aim for maximum
> efficiency.

Maybe you're right, I don't know. I just find it makes me kind of 
nervous working with something which can break just because you changed 
the order of a few statements in a way which, conceptually, shouldn't 
change anything.

(Notice that guy who said he couldn't just add a new integer field to a 
data structure because it would break a few thousand other functions? 
Does that sound like good abstraction you to?)

Still, I guess that's why I'm not a games developer...

I was also puzzled when I looked at Gentoo and discovered just how many 
C programs break horribly just because they were written for IA-32 and 
got recompiled for AMD64.

Post a reply to this message