Exception Handling

[UnderDog]

Asking for too much.


To me it is more or less defined - you either get a memory access violation OR you do not. If you do not get a memory access violation then your extra write probably trashed some other data in your program. Nothing else can happen. If your program writes beyond an array bound

1. Then unless your program is really tracking each memory write, the program is not going to know of that.
2. It is the CPU which MAY detect something amiss. CPU can detect something amiss only and only if the memory address beyond the array was not allocated by your program. If that array e.g. is on heap and ends at an address 0x100, then probably 0x101 is still memory that belongs to your program's heap and CPU will not find anything wrong with that.

So you get an exception in some cases where the memory being written to does not belong to your program and in another cases you do not get an exception. To me that is more or less defined. The compilers are NOT adding any behavior to it because it is simply not in control of the language. What I mean to say is that in this case, in my opinion, compiler vendors do not look at the standards, see the behavior is undefined, and then go ahead add some behavior of their own. They simply can't. So talking to C++ guys is not an option . Alternative is to have C++ introduce it's own sophisticated memory management aka C#, Java etc. OR e.g. trap each access to memory via pointers OR ban pointers.


Now talking to CPU vendors may help - e.g. some day the CPU start understanding 'arrays' and other program level data variables and start writing dead bytes beyond the variable limits to detect out of bound accesses - waste of memory. Array is just one example. e.g. you can run into the same situation e.g. when you write a 4 byte integer value (through pointers) to a variable that was declared short (2 bytes). will require too much tracking on the CPU part.

[SuperKoko]

So talking to C++ guys is not an option . Alternative is to have C++ introduce it's own sophisticated memory management aka C#, Java etc. OR e.g. trap each access to memory via pointers OR ban pointers.

Do you know that there exists a few bound checked implementations (CINT being one of them).
Anyway, I think that if you really do want bound checks everywhere you should use std::vector::at. You can even derive from std::vector (even though that might be deemed as bad) and hide operator[] with a bound-checking operator[].


Banning pointers is not an option... It's a notion required to make C++ as powerful as it is... In particular pointers are useful for manipulating low-level structures (C++ can be used at a low level) as well as a fundation for high-level abstractions.

If C++ doesn't met your requirements, you should not be using it.
Instead of trying to make C++ adapt to you, you should choose a language adapted to you.

Now talking to CPU vendors may help - e.g. some day the CPU start understanding 'arrays' and other program level data variables and start writing dead bytes beyond the variable limits to detect out of bound accesses - waste of memory.

It wouldn't help at all. It would not make array access faster and would require far more transistors... It would be an Hyper-CISC architecture... Slow and inefficient.
There has been real-world hardware trying to adapt to high-level languages... They failed miserably. Software must adapt to hardware, not the opposite.

Support for this sort of thing is better in software. Moreover Java implementations are even able to do *real* optimizations that a CPU could never do, such as detecting loops like:

for(int i=0;i<arr.length;i++) {
 // Code that uses arr[i]
}

And remove bound checks because "i < arr.length" implies that the bound check is not necessary.

Theorically, C++ implementations are allowed to do this optimization for std::vector::at but usually they don't because they prefer useful optimizations, and the coding style of C++ programmers are different from the coding styles of Java programmers and leads to very different optimization needs.

PS: You're not the only man on earth wanting to tranform the C++ language into something closer to his favorite language... If we've several programming languages that's because they are useful for different things... If you've a project for which C++ is not the right tool but smalltalk is... Instead of modifying the hundred of C++ implementations on earth, you'd better write this project in smalltalk.
Similarly, I highly doubt you'll convince a standard committee to change specifications of CD-ROMs because they're really not good when you try to eat them and you'd prefer that they contain sugar, flour and butter, like your favorite cake!

[KevinHall]

-- Oops... should have been a PM --