Simon said:
Interesting. Is that because, on your architecture, 0xFFFF is -0? (I'm
just guessing.)
No, "divide by zero" can occure not only while you are dividing by 0,
in many cases, when CPU can not store result, that even can take more
memory, than source and divider have together.
Unsufficient memory can happends, when we are dividing very big number
to very small number ( due to CPU hardware limitations ), when divider
less than 1 (for floationg point) and 0 is just a limit of all here, as
most small number. Mathematically, to store result from 0 we need
memory of unlimited size.
But we don't want the unnecessary overhead when there's no possibility
of divide-by-zero. C++ leaves it to the programmer to decide whether or
not checks are needed, rather than imposing such checks.
1. "Divide by zero" in most cases is error, for result is not the same,
as expect programmer. If it does not matter to him to get the concrete
result, why is he dividing? It is better to do addition - faster and
safe operation
2. We must report ALL errors to apropriate handler. Always. It is not
"overhead".
3. "Divide by zero" handled by CPU practicaly, already handled,
similarly "bad memory access". Do we throw in the cases or silently
call exit()?
Lets programmer make selection. To do it, standard must allow for
programmer to make selection between "throw" or "not throw".
Now C++ programmer can not throw easy, No one of way below is allowed
by standard:
a) check a std:: flag _divide_error
a/=b; if(std::_divide_error)throw bad_divide();
b) do automatic throw
try{ a/=b; }catch(...){}
and programmer can not do local selection of one of them.
4. Not only "Divide by zero", all processable harware errors must be
processed as point 3. I think.
Sorry, I just didn't understand that. "try to find a cause of it"? "if
we will not find any, we will not process the error also"?
Well,well:
try - verb, "to attempt to do any"
will try - future indefinite of try
to find - verb infinitive, "make a search of any"
will try to find - will try in order to find
a - "any kind of next noun"
cause - noun, "source of an action, root"
of - "cause of thunder" is "thunder cause"
it - you know what is "it"
and so on,
Ask if need more explanations
I didn't understand the second half of that. But as for "may be is not
a best solution, because most CPUs can handle the error", the problem is
that (as I understand it) the operating system deals with such things.
it is not easy for programmer, that OS will do anything with his error,
OS can not repair his program. Programmer want to restore after errors
and C++ exceptions one of the way to do it.
Different operating systems deal with such things in different ways.
Yes, and C++ exceptions is one of the way to hide the differences.
And, as I said above, such things are beyond the scope of the C++
specification.
No, the question of safe and predictable excution is not beyond scope
of the C++, but bridge between "throw" and "CPU" of course beyond scope
of the C++.
Such checking only needs to be done in those cases where undefined
behaviour would otherwise be possible, and would be unacceptable. Such
checks don't need to be done for those cases where such undefined
behaviour isn't able to occur anyway.
The "checks" already is being doing by CPU, you can not deny "checks"
and you must do not do something for "checks". If no errors accured -
no "checks" will happen.
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
In the case of "divide by zero" , we are speaking excactly about that
C++ does not provides tools to help the programmer write safe code. No
tools.