Darren New wrote: > The compiler can look at that and know that i never goes out of bounds > and not bother to generate array bounds checks.
Yeah... any good optimizer will do this for you. C++ actually makes its job easier. > Even if you managed something like that in C++, you'd still then have > the problem of things like other threads stomping on variables > inappropriately, such that the optimized code doesn't do what the > unoptimized code does. No, in C and C++, unless you have a variable tagged as volatile and/or a memory barrier, the optimizer is free to assume that nobody else can mess with the variable but the current thread. Java's runtime specification has something similar (although it trades off a bit of performance for better concurrency semantics). > *That* is why language designers build stuff into the language > instead of putting everything in libraries. No, they put stuff like that in for the reason you originally highlighted: the vast majority of the time, you want the check there, and when you don't... you can use C/C++. Unfortunately that proves to be a poor argument for C/C++. ;-) You could change the default behavior and provide an override, but then you'd break way too much code. >> I don't see why knowing that you've got >> guaranteed checks prior to dereferencing in C++ ought to add more >> cognitive load than knowing that in some other language. > > The cognitive load is deciding each time whether you need a checked > pointer or an unchecked pointer. If you *never* need an unchecked > pointer, why isn't it built in? That cognitive load exists all the time. This is part of the reason you'll find every high level language has C bindings. You always have the option of doing bits of code in C. You just don't think about it much because most of the time the answer is obvious. No reason it can't be the same way in C++. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
