|
![](/i/fill.gif) |
Warp wrote:
> Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |