132  5438 
On 2007-01-12 23:28, Erik Wikström wrote:
On 2007-01-12 22:24, Zorro wrote:
>Simon G Best wrote:
Erik says "It means that if you have code with a catch-block that
gets executed even though no exception has been thrown it is not
standard compliant behavior, I would even go as far as saying that it
is in direct violation of the standard".
A very specific and clear statement. But again, Erik immediately brings
up undefined behavior.
Sorry if that was unclear, what I meant to say was that while I can't
cite any specific part of the standard I'm quite sure that it specifies
that all exceptions have to be throw. As no such things happens in your
example I claim that there is no exception.
Sorry, no, that is not what I meant. My only excuse is that it's quite
late. What I really meant was that I'm quite sure that the standard
specifies that the code in a catch-block may only be executed if an
exception is thrown in the preceding try-block. So executing the catch-
block when no exception has been thrown is in violation of the standard.
--
Erik Wikström
On 2007-01-12 23:23, Zorro wrote:
In response to several comments after this posting:
Let us be fair. Do not reply to a paragraph, somewhat out ot context. I
am asking a couple of specific questions. If someone is familiar with
the standard, please point out where should we look in the standard.
Please, kindly show an example, and your choice of compiler, as I have
requested. Some of the comments simply say "Only MS VC++ does that".
Well, can you create an example using another compiler that does not?
Playing with words can go on forever, such as "An exception that is not
thrown is not an exception".
It's not, chapter 15, first paragraph states:
Exception handling provides a way of transferring control and
information from a point in the execution of a program to an exception
handler associated with a point previously passed by the execution. A
handler will be invoked only by a throw-expression invoked in code
executed in the handler’s try block or in functions called from the
handler’s try block.
The handler here is the catch-block.
--
Erik Wikström
Erik Wikström wrote:
On 2007-01-12 22:24, Zorro wrote:
Simon G Best wrote:
Erik says "It means that if you have code with a catch-block that
gets executed even though no exception has been thrown it is not
standard compliant behavior, I would even go as far as saying that it
is in direct violation of the standard".
A very specific and clear statement. But again, Erik immediately brings
up undefined behavior.
Sorry if that was unclear, what I meant to say was that while I can't
cite any specific part of the standard I'm quite sure that it specifies
that all exceptions have to be throw. As no such things happens in your
example I claim that there is no exception.
Is "undefined behavior", in this context, mentioned in the
standard? It will be nice someone familiar with standard to kindly
tells us where this is stated.
[snip]
The best way to resolve this is an answer like this. Standard item
number such and such states that .... Or, standard does not address
this issue for now.
I don't own a copy of the standard but I've got a copy of a draft for
the next standard, which I hope will suffice.
1.3.13 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct
or erroneous data, for which this International Standard mposes no
requirements. Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition
of behavior. [ Note: permissible undefined behavior ranges from ignoring
the situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic
of the environment (with or without the issuance of a diagnostic
message), to terminating a translation or execution (with the issuance
of a diagnostic message). Many erroneous program constructs do not
engender undefined behavior; they are required to be diagnosed. -end note]
The following might also be of interest:
5.6 Multiplicative operators [expr.mul]
4th paragraph
The binary / operator yields the quotient, and the binary % operator
yields the remainder from the division of the first expression by the
second. If the second operand of / or % is zero the behavior is
undefined; otherwise (a/b)*b + a%b is equal to a. If both operands are
nonnegative then the remainder is nonnegative; if not, the sign of the
remainder is implementation-defined).
Hope that helps.
--
Erik Wikström
Yes Erik, it helps me completely. Thanks. I actually needed this info
for improving on the article. Good night.
Regards.
Ian Collins wrote:
Zorro wrote:
In response to several comments after this posting:
Let us be fair. Do not reply to a paragraph, somewhat out ot context. I
am asking a couple of specific questions. If someone is familiar with
the standard, please point out where should we look in the standard.
This is out of the scope of the standard!
Please, kindly show an example, and your choice of compiler, as I have
requested. Some of the comments simply say "Only MS VC++ does that".
Well, can you create an example using another compiler that does not?
Playing with words can go on forever, such as "An exception that is not
thrown is not an exception".
Please show an example that does not do what I am saying is happening.
Do not simply say that it is not happening. Show us how it is not
happening.
This is becoming tedious.
Your own example:
#include <iostream>
struct simple
{
int s;
simple() { s = 5;}
~simple(void) {std::cout << "Destructor ..." << std::endl;}
};
int main(){
int i = 1, j = 0;
try {
simple spl;
int k = i/j;
}
catch(...) {
std::cout << "Caught it" << std::endl;
}
std::cout << "Finishing" << std::endl;
return 0;
}
compiled with gcc on Solaris or Linux aborts.
./a.out
Arithmetic Exception (core dumped)
--
Ian Collins.
Yes Ian. gcc gave me "Floating point Exception". The compilers from
Metrowerks, Borland and MS were on PC and it seemed sufficient to show
the problem, without trying a free compiler (and retyping the program).
That proved to be wrong.
Thanks.
Regards.
Simon G Best wrote:
Just to clarify...
Ian Collins wrote:
./a.out
Arithmetic Exception (core dumped)
That "Arithmetic Exception", I bet, is *not* a C++ exception, but some
other kind of exception beyond C++. (Just thought I'd better clarify
that, just in case Zorro mistakes it for a C++ exception.)
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
No Simon, I do not mistake it. This exception is equivalent to a crash,
as one would expect to happen.
Regards.
benben wrote:
>
C++ could have properly throw an exception when you try to divide an int
by zero. However, this will put up a significant performance penalty
that not everyone is comfortable with. Alternatively, you can simple
test the divident and throw your own exception:
if (j == 0)
throw divide_by_zero();
i /= j;
Can not, divide by zero can happen not only for zero, try divide 0xffff
to 0x02, test it in debug
write to file:"
r ax
ffff
r dx
2
a
div dl
r
t
q
"
write to command line:"
>debug <file
"
But compiler easy can setup trap for the error and throw divide_by zero
exception.
It seems to me, that there is no std::divide_by zero exception, so it
is really interesting problem, thanks Zorro.
Simon G Best wrote:
I f the C++ standard was to specify behaviour for division by zero, then
since the processor's behaviour and operating system's behaviour are
beyond the scope of the C++ standard, such specified behaviour may well
have to be implemented in such a way as to prevent the division by zero
from actually occurring in the first place. That would impose often
unnecessary and unwanted overheads. C++ just isn't that sort of language.
It looks like " We do not want to process the error, and will try to
find a cause of it, if we will not find any, we will not process the
error also. Abtreten! " :)
Speaking seriously, the ignoring the error as "undefined behaviour" may
be is not a best solution, because most CPUs can handle the error and
compilers must do good workaround (they do not do it itself), and if
CPU can not, the kind of C++ exception just will never appear.
I think, user can not effective manage the error, because can not jump
to hidden catch entry point directly, because trap can be executed in
other task(process) from which user can not throw, so user must do
unneccessary if-else after each divide operation, that is no good.
Grizlyk wrote:
>
Can not, divide by zero can happen not only for zero, try divide 0xffff
to 0x02, test it in debug
Interesting. Is that because, on your architecture, 0xFFFF is -0? (I'm
just guessing.)
But compiler easy can setup trap for the error and throw divide_by zero
exception.
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.
Simon G Best wrote:
>>I f the C++ standard was to specify behaviour for division by zero, then
since the processor's behaviour and operating system's behaviour are
beyond the scope of the C++ standard, such specified behaviour may well
have to be implemented in such a way as to prevent the division by zero
from actually occurring in the first place. That would impose often
unnecessary and unwanted overheads. C++ just isn't that sort of language.
It looks like " We do not want to process the error, and will try to
find a cause of it, if we will not find any, we will not process the
error also. Abtreten! " :)
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"?
Speaking seriously, the ignoring the error as "undefined behaviour" may
be is not a best solution, because most CPUs can handle the error and
compilers must do good workaround (they do not do it itself), and if
CPU can not, the kind of C++ exception just will never appear.
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.
Different operating systems deal with such things in different ways.
And, as I said above, such things are beyond the scope of the C++
specification.
I think, user can not effective manage the error, because can not jump
to hidden catch entry point directly, because trap can be executed in
other task(process) from which user can not throw, so user must do
unneccessary if-else after each divide operation, that is no good.
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.
For example, let's suppose that a program is going to be reading in some
data from somewhere. Let's also suppose that it's possible for that
data to be 'incorrect' in some way (even though it's obviously not
supposed to be incorrect, it still might be). And let's also suppose
that we need that program to behave well even when 'incorrect' data is
given to it. And finally, let's suppose it's possible for that data to
be 'incorrect' in such a way that normal processing of that data could
involve division by zero.
In order to have that program behave well when given such 'incorrect'
data, we're going to have to check the data somehow, and take
appropriate action when that data's 'incorrect'. That's the sort of
thing we can use exceptions for. (And we may well have that data
checking some way before it even gets close to any of the relevant
divisions, so we might not even have to specifically check for division
by zero.)
In contrast, if part of a program can't ever end up trying to do
something like division by zero, then there's no need to check for such
things as division by zero. No need to add the extra overhead of
checking for such cases when such cases can't arise anyway. For example:-
int foo (int x) {
for (int i(1); i <= 10; ++i) // i can't ever be zero, so
x /= i; // no check is ever needed.
return x;
}
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
:-)
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon G Best wrote:
>
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
:-)
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Thanks to all comments, and in particular yours (to my blogger) I
realized I had made a slieght error because multiple compilers gave me
the same result (on Windows). My apologies. However ...
I have redone the blogger, and the article to show the disadvantages of
C++ exception model, and a better way of doing things. Looking at your
comment (above) I do not see what you are really trying to say. What do
you mean by "C++ does not impose safety on the programmer". So, how
come you cannot call a private method? It is the purpose of a modern
language to help with the safety.
Then you say "C++ provides tools ....". Does C not do that already? So
why use C++?
Now, reread the article, without prejudice. I love C++ and I have known
it from the time before it was called C++. My argument is that,
someone's weak implementation techniques were forced into standard, and
your generation simply takes that as a religion.
Regards.
"Zorro" <zo****@comcast.netwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...
>
Simon G Best wrote:
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
:-)
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Thanks to all comments, and in particular yours (to my blogger) I
realized I had made a slieght error because multiple compilers gave me
the same result (on Windows). My apologies. However ...
I have redone the blogger, and the article to show the disadvantages of
C++ exception model, and a better way of doing things. Looking at your
comment (above) I do not see what you are really trying to say. What do
you mean by "C++ does not impose safety on the programmer". So, how
come you cannot call a private method?
Different kind of safety. Calling a private function wouldn't necessarily be
unsafe, at least not _because_ the function is private. OTOH, you can happily
dereference uninitialized pointers and other unsafe things.
It is the purpose of a modern
language to help with the safety.
Different languages have different goals. One of C++'s is to have minimal
overhead. If C++ doesn't suit your purpose, then choose another language.
Then you say "C++ provides tools ....". Does C not do that already? So
why use C++?
What do tools have to do with whether to use C or C++, given the vast array of
differences between the two languages?
DW
David W wrote:
What do tools have to do with whether to use C or C++, given the vast array of
differences between the two languages?
At least I thought the term tool (in context) meant linguistic
constructs, not tools external to the language itself. Sorry about
that. The vast array of differences were intended to ease development,
and for the most part they do.
Different languages have different goals. One of C++'s is to have minimal
overhead. If C++ doesn't suit your purpose, then choose another language.
I believe, in this one case, we are simply talking about the usefulness
of the C++ exception model. Is it really due to the significant
efficiency that C++ provides, that there is no resumption, for
instance. Or perhaps it has something to do with a form of
implementation that has been accepted as standard?
Different kind of safety. Calling a private function wouldn't necessarily be
unsafe, at least not _because_ the function is private. OTOH, you can happily
dereference uninitialized pointers and other unsafe things.
No language can ever be completely safe. The intent is to move towards
a safer language, just as the introduction of "class" made a better C.
So now, all I am saying about C++ exception is that, it was not
well-thought. There is no need to change to a different language. The
standard can take a closer look and re-evaluate the benefits of the
current model. At least we can point out to other ideas by citing other
languages. One can close his ears to any argument by continually
bringing up "overhead". So be it.
Thanks for your comments.
Regards.
* Zorro:
Is it really due to the significant
efficiency that C++ provides, that there is no resumption, for
instance. Or perhaps it has something to do with a form of
implementation that has been accepted as standard?
Rather it's about safety. Microsoft wanted resumption, but didn't
manage to convince any others (IIRC). Mostly the idea of correcting and
resuming at the C++ or machine code instruction level is just Wrong;
however, it is a valid option at the block or function level, like the
exception handling in Eiffel, a retry of some higher level instead of
resumption. To emulate the Eiffel exception handling in C++ you can use
the template pattern (which has nothing to do with C++ templates, look
it up if you haven't heard about it). It would of course be more
practical & useful if C++ had closures...
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote:
* Zorro:
Is it really due to the significant
efficiency that C++ provides, that there is no resumption, for
instance. Or perhaps it has something to do with a form of
implementation that has been accepted as standard?
Rather it's about safety. Microsoft wanted resumption, but didn't
manage to convince any others (IIRC). Mostly the idea of correcting and
resuming at the C++ or machine code instruction level is just Wrong;
however, it is a valid option at the block or function level, like the
exception handling in Eiffel, a retry of some higher level instead of
resumption. To emulate the Eiffel exception handling in C++ you can use
the template pattern (which has nothing to do with C++ templates, look
it up if you haven't heard about it). It would of course be more
practical & useful if C++ had closures...
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Thank you for your comment. If I go over everything you have packed in
one paragraph, this will go on forever. Just one point: MS has hardly
cared about convincing others to do what it wants to do. Otherwise it
would comply with the standard.
I am not, in any way, trying to extend the points you have made to a
lengthy discussion. Thanks again.
Regards.
Zorro wrote:
David W wrote:
>>
Different languages have different goals. One of C++'s is to have minimal
overhead. If C++ doesn't suit your purpose, then choose another language.
I believe, in this one case, we are simply talking about the usefulness
of the C++ exception model. Is it really due to the significant
efficiency that C++ provides, that there is no resumption, for
instance. Or perhaps it has something to do with a form of
implementation that has been accepted as standard?
The C++ exception model is designed for C++ generated exceptions, not
for asynchronous events generated form outside.
>
>>Different kind of safety. Calling a private function wouldn't necessarily be
unsafe, at least not _because_ the function is private. OTOH, you can happily
dereference uninitialized pointers and other unsafe things.
No language can ever be completely safe. The intent is to move towards
a safer language, just as the introduction of "class" made a better C.
So now, all I am saying about C++ exception is that, it was not
well-thought. There is no need to change to a different language. The
standard can take a closer look and re-evaluate the benefits of the
current model. At least we can point out to other ideas by citing other
languages. One can close his ears to any argument by continually
bringing up "overhead". So be it.
Overhead isn't the point at issue, differentiating between exceptions
thrown by the application and asynchronous events generated by the
operating environment is.
--
Ian Collins.
Zorro wrote:
I believe, in this one case, we are simply talking about the usefulness
of the C++ exception model. Is it really due to the significant
efficiency that C++ provides, that there is no resumption, for
instance. Or perhaps it has something to do with a form of
implementation that has been accepted as standard?
You can read "The Design and Evolution of C++". It explains the rationale of
a bunch of design decisions.
--
Salu2
Ian Collins wrote:
Zorro wrote:
David W wrote:
>
Different languages have different goals. One of C++'s is to have minimal
overhead. If C++ doesn't suit your purpose, then choose another language.
I believe, in this one case, we are simply talking about the usefulness
of the C++ exception model. Is it really due to the significant
efficiency that C++ provides, that there is no resumption, for
instance. Or perhaps it has something to do with a form of
implementation that has been accepted as standard?
The C++ exception model is designed for C++ generated exceptions, not
for asynchronous events generated form outside.
>Different kind of safety. Calling a private function wouldn't necessarily be
unsafe, at least not _because_ the function is private. OTOH, you can happily
dereference uninitialized pointers and other unsafe things.
No language can ever be completely safe. The intent is to move towards
a safer language, just as the introduction of "class" made a better C.
So now, all I am saying about C++ exception is that, it was not
well-thought. There is no need to change to a different language. The
standard can take a closer look and re-evaluate the benefits of the
current model. At least we can point out to other ideas by citing other
languages. One can close his ears to any argument by continually
bringing up "overhead". So be it.
Overhead isn't the point at issue, differentiating between exceptions
thrown by the application and asynchronous events generated by the
operating environment is.
--
Ian Collins.
Thanks and regards.
Julián Albo wrote:
Zorro wrote:
I believe, in this one case, we are simply talking about the usefulness
of the C++ exception model. Is it really due to the significant
efficiency that C++ provides, that there is no resumption, for
instance. Or perhaps it has something to do with a form of
implementation that has been accepted as standard?
You can read "The Design and Evolution of C++". It explains the rationaleof
a bunch of design decisions.
--
Salu2
Thank you.
Regards.
Simon G Best wrote:
Zorro wrote:
Whether or not a raised exception is "thrown", the control from the try
block makes a jump to the catch() section. That is what I meant by
"catching none-thrown exceptions".
Exceptions are raised *by throwing them.* In C++, that's what raising
an exception is. You can't have a raised exception that isn't thrown,
because you can't have a /thrown/ exception that isn't thrown.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Mr. Best. I accidently went to the Z++ page in Wikipedia and saw your
interference. So I decided to reply to your comment, even though I wish
this thread to end immediately.
When you run the example that Ian did on Linux, you get "Arithmetic
Exception" and a crash. That means an exception was raised at a "level"
outside of scope of C++. Read my statement, and your comment to it
again to see if you are making any sense.
With all the respect, I am not interested in persuing this matter.
Regards.
On Jan 14, 9:39 pm, "Zorro" <zor...@comcast.netwrote:
Simon G Best wrote:
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
What do you mean by "C++ does not impose safety on the programmer".
So, how come you cannot call a private method? It is the purpose of a
modern language to help with the safety.
Then you say "C++ provides tools ....". Does C not do that already? So
why use C++?
C++ does not impose safety on the programmer by not requiring that the
safety-features are used, you can write very unsafe code in C++ if you
choose to. But C++ does provide features (such as private) that enables
the user to write safe code (these kind of things are the tools Simon
was referring to).
--
Erik Wikström
Simon G Best wrote:
Grizlyk wrote:
Can not, divide by zero can happen not only for zero, try divide 0xffff
to 0x02, test it in debug
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 compiler easy can setup trap for the error and throw divide_by zero
exception.
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.
It looks like " We do not want to process the error, and will try to
find a cause of it, if we will not find any, we will not process the
error also. Abtreten! " :)
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 :)
Speaking seriously, the ignoring the error as "undefined behaviour" may
be is not a best solution, because most CPUs can handle the error and
compilers must do good workaround (they do not do it itself), and if
CPU can not, the kind of C++ exception just will never appear.
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++.
I think, user can not effective manage the error, because can not jump
to hidden catch entry point directly, because trap can be executed in
other task(process) from which user can not throw, so user must do
unneccessary if-else after each divide operation, that is no good.
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.
"Zorro" <zo****@comcast.netwrote in
news:11**********************@q2g2000cwa.googlegro ups.com:
>
Simon G Best wrote:
>Zorro wrote:
>
Whether or not a raised exception is "thrown", the control from the
try block makes a jump to the catch() section. That is what I meant
by "catching none-thrown exceptions".
Exceptions are raised *by throwing them.* In C++, that's what
raising an exception is. You can't have a raised exception that
isn't thrown, because you can't have a /thrown/ exception that isn't
thrown.
Mr. Best. I accidently went to the Z++ page in Wikipedia and saw your
interference. So I decided to reply to your comment, even though I
wish this thread to end immediately.
When you run the example that Ian did on Linux, you get "Arithmetic
Exception" and a crash. That means an exception was raised at a
"level" outside of scope of C++. Read my statement, and your comment
to it again to see if you are making any sense.
However, you are confusing two different things. The "Arithmetic
Exception" is not an exception in the C++ sense of the word. If that error
message had read "Arithmetic FUBAR", would that help? Attempting to
"catch" this type of exception (directly) makes no sense at all.
With all the respect, I am not interested in persuing this matter.
Usenet threads take on a life of their own... regardless of the
originator's wishes.
Grizlyk wrote:
Simon G Best wrote:
[snip]
>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.
That is not entirely correct: you can write a wrapper template for the
arithmetic types. I confine myself to a rough outline. Also, I will
acknowledge that it is impossible to make such wrappers behave exactly like
the built in types (e.g., with regard to automatic promotions and
conversions). However, in many cases, such a wrapper can be used. E.g., for
debugging pointers, I do use a smart pointer whose operator* method does
assert( underlying_pointer != 0 ).
#include <stdexcept>
#include <string>
struct divide_by_zero : public std::out_of_range {
divide_by_zero ( std::string const & msg )
: std::out_of_range( msg )
{}
}; // divide_by_zero
template < typename ArithmeticType >
struct throw_divide_by_zero {
typedef ArithmeticType base_type;
explicit
throw_divide_by_zero ( base_type x = 0 )
: data ( x )
{}
friend
throw_divide_by_zero operator+ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
// many more friends
// ...
// and finally, division:
friend
throw_divide_by_zero operator/ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
if( rhs.data == 0 ) {
throw ( divide_by_zero( std::string( "division by 0" ) ) );
}
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
private:
base_type data;
}; // throw_divide_by_zero
#include <iostream>
int main ( void ) {
try {
throw_divide_by_zero<inta ( 0 );
throw_divide_by_zero<intb ( 3 );
b / a;
}
catch ( divide_by_zero const & c ) {
std::cout << c.what() << '\n';
}
}
Best
Kai-Uwe Bux
Kai-Uwe Bux wrote:
Grizlyk wrote:
Simon G Best wrote:
[snip]
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.
That is not entirely correct: you can write a wrapper template for the
arithmetic types. I confine myself to a rough outline. Also, I will
acknowledge that it is impossible to make such wrappers behave exactly like
the built in types (e.g., with regard to automatic promotions and
conversions). However, in many cases, such a wrapper can be used. E.g., for
debugging pointers, I do use a smart pointer whose operator* method does
assert( underlying_pointer != 0 ).
#include <stdexcept>
#include <string>
struct divide_by_zero : public std::out_of_range {
divide_by_zero ( std::string const & msg )
: std::out_of_range( msg )
{}
}; // divide_by_zero
template < typename ArithmeticType >
struct throw_divide_by_zero {
typedef ArithmeticType base_type;
explicit
throw_divide_by_zero ( base_type x = 0 )
: data ( x )
{}
friend
throw_divide_by_zero operator+ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
// many more friends
// ...
// and finally, division:
friend
throw_divide_by_zero operator/ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
if( rhs.data == 0 ) {
throw ( divide_by_zero( std::string( "division by 0" ) ) );
}
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
private:
base_type data;
}; // throw_divide_by_zero
#include <iostream>
int main ( void ) {
try {
throw_divide_by_zero<inta ( 0 );
throw_divide_by_zero<intb ( 3 );
b / a;
}
catch ( divide_by_zero const & c ) {
std::cout << c.what() << '\n';
}
}
Best
Kai-Uwe Bux
Kai-Uwe, this is nice. However, look at all the code you have written
for something so simple. And you also expect everyone to remember how
to do such things in all cases, possibly in complex situations?
I am not entering the discussion. I was just wondering if you thought
about your extensive creativity.
Regards.
Erik Wikström wrote:
On Jan 14, 9:39 pm, "Zorro" <zor...@comcast.netwrote:
Simon G Best wrote:
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
What do you mean by "C++ does not impose safety on the programmer".
So, how come you cannot call a private method? It is the purpose of a
modern language to help with the safety.
Then you say "C++ provides tools ....". Does C not do that already? So
why use C++?
C++ does not impose safety on the programmer by not requiring that the
safety-features are used, you can write very unsafe code in C++ if you
choose to. But C++ does provide features (such as private) that enables
the user to write safe code (these kind of things are the tools Simon
was referring to).
--
Erik Wikström
Erik, I am not sure where you disagree with me. I understand what Simon
means by tools. Then, I am saying that the use of those tools imposes
restrictions (if you will). A C++ programmer not using C++ features is
a human decision. The language cannot impose upon you to use it one way
or the other. Finally, I am saying that, C has sufficient features to
be used safely. The conclusion I am drawing is that, the reason for
something like private is so you can avoid mistakes in a large program.
I admit I made it very brief, but that is what I meant.
Regards.
Andre Kostur wrote:
"Zorro" <zo****@comcast.netwrote in
news:11**********************@q2g2000cwa.googlegro ups.com:
Simon G Best wrote:
Zorro wrote:
Whether or not a raised exception is "thrown", the control from the
try block makes a jump to the catch() section. That is what I meant
by "catching none-thrown exceptions".
Exceptions are raised *by throwing them.* In C++, that's what
raising an exception is. You can't have a raised exception that
isn't thrown, because you can't have a /thrown/ exception that isn't
thrown.
Mr. Best. I accidently went to the Z++ page in Wikipedia and saw your
interference. So I decided to reply to your comment, even though I
wish this thread to end immediately.
When you run the example that Ian did on Linux, you get "Arithmetic
Exception" and a crash. That means an exception was raised at a
"level" outside of scope of C++. Read my statement, and your comment
to it again to see if you are making any sense.
However, you are confusing two different things. The "Arithmetic
Exception" is not an exception in the C++ sense of the word. If that error
message had read "Arithmetic FUBAR", would that help? Attempting to
"catch" this type of exception (directly) makes no sense at all.
I did not say "Arithmetic Exception" is any form of C++ exception.
Please note what I am saying.
Exceptions occur at various levels of a system (CPU, layers of OS).
Each layer, either can handle the problem, or passes it to the next
layer. Now, if you wish to handle "Arithmetic Exception" in C++, you
need to throw it within C++. But whether you do, or do not throw the
exception in C++, somewhere in the system the exception will be raised.
It is an exception, and is not a FUBAR. Just because it was not thrown
within a C++ program does not change it to a FUBAR.
Requiring to throw exceptions that are expected to be caught is a
decision. It is not related to making or not making sense.
Hope this helps.
With all the respect, I am not interested in persuing this matter.
Usenet threads take on a life of their own... regardless of the
originator's wishes.
OK Andre. I must agree with you in that. Whether I can keep up with it
remains to be seen. Sometimes an incorrect use of a word (as it can
happen at this time of night) starts a whole new spark.
Regards.
On Jan 15, 10:36 am, "Zorro" <zor...@comcast.netwrote:
Erik Wikström wrote:
On Jan 14, 9:39 pm, "Zorro" <zor...@comcast.netwrote:
Simon G Best wrote:
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
What do you mean by "C++ does not impose safety on the programmer".
So, how come you cannot call a private method? It is the purpose of a
modern language to help with the safety.
Then you say "C++ provides tools ....". Does C not do that already? So
why use C++?
C++ does not impose safety on the programmer by not requiring that the
safety-features are used, you can write very unsafe code in C++ if you
choose to. But C++ does provide features (such as private) that enables
the user to write safe code (these kind of things are the tools Simon
was referring to).
--
Erik WikströmErik, I am not sure where you disagree with me. I understand what Simon
means by tools. Then, I am saying that the use of those tools imposes
restrictions (if you will). A C++ programmer not using C++ features is
a human decision. The language cannot impose upon you to use it one way
or the other. Finally, I am saying that, C has sufficient features to
be used safely. The conclusion I am drawing is that, the reason for
something like private is so you can avoid mistakes in a large program.
I admit I made it very brief, but that is what I meant.
I was only giving an answer to the question 'What do you mean by "C++
does not impose safety on the programmer"'.
--
Erik Wikström
On Jan 15, 8:33 am, "Grizlyk" <grizl...@yandex.ruwrote:
Simon G Best wrote:
Grizlyk wrote:
Can not, divide by zero can happen not only for zero, try divide 0xffff
to 0x02, test it in debug
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.
Correct me if I'm wrong but is not this caused by the way floating
point arithmetic is performed? I seem to recall that first the numbers
are modified so that they have the same exponent, and while doing this
I suspect that the mantissa can become so small that it is rounded to
0, in which case the division will be by 0.
--
Erik Wikström
Zorro wrote:
Andre Kostur wrote:
However, you are confusing two different things. The "Arithmetic
Exception" is not an exception in the C++ sense of the word. If that error
message had read "Arithmetic FUBAR", would that help? Attempting to
"catch" this type of exception (directly) makes no sense at all.
I did not say "Arithmetic Exception" is any form of C++ exception.
Please note what I am saying.
Exceptions occur at various levels of a system (CPU, layers of OS).
Each layer, either can handle the problem, or passes it to the next
layer. Now, if you wish to handle "Arithmetic Exception" in C++, you
need to throw it within C++. But whether you do, or do not throw the
exception in C++, somewhere in the system the exception will be raised.
It is an exception, and is not a FUBAR. Just because it was not thrown
within a C++ program does not change it to a FUBAR.
Yes, it does. It seems to me reading this thread that your entire
question is based on coincidence. CPU designers have the concept of
what happens in awkward situations like divide by zero, and C++
programmers have the concept of what happens in responce to a throw
statement, and while those two concepts are utterly unrelated, both
groups of people (CPU designers and C++ programmers) happen to have
chosen the word "exception" to describe their concept.
If CPU designers had instead chosen the word "FUBAR" for their concept,
and C++ programmers had chosen the word "tadpole" for theirs, do you
really think your original question would have arisen?
Gavin Deane
Kai-Uwe Bux wrote:
Grizlyk wrote:
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.
That is not entirely correct: you can write a wrapper template for the
arithmetic types.
No, we can not write wrapper, because "divide by zero" error rising in
CPU, out of C++ scope.
1. C++ compiler can install low-level error handler, that will silently
ignore the error, but standard _do not require_ it.
2. C++ compiler can install low-level error handler, that will throw
(user can not generate throw from low-level error handler), but
standard _do not require_ it.
3. C++ compiler can install low-level error handler, that will set
errno (user sometimes can do it from low-level error handler), but
standard _do not require_ it.
In theory, compiler can generate exception even when overflow has
occured while addition operation. Let it is discussable.
But in the case of "divide by zero" very often is only way to handle
the error is terminating program, due to hardware unmaskable CPU rised
signal, not program rised. You can not write low-level handler for
concrete target system in order to continue execution.
So i think C++ standart at least must garantee, that no differences
will be for overflow at addition or divide operations (for example,
silently ignore errors or ignore & setup error flag).
Grizlyk wrote:
Kai-Uwe Bux wrote:
Grizlyk wrote:
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.
That is not entirely correct: you can write a wrapper template for the
arithmetic types.
No, we can not write wrapper, because "divide by zero" error rising in
CPU, out of C++ scope.
Have you missed the point? In C++, the built in arithmetic types
provide no protection against divide-by-zero. If the code calls for
divide-by-zero, it will compile. What then happens at run-time is not
defined by the C++ stadard. But you snipped Kai-Uwe's code which showed
a wrapper template that included the following overloaded operator:
<quote>
friend
throw_divide_by_zero operator/ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
if( rhs.data == 0 ) {
throw ( divide_by_zero( std::string( "division by 0" ) ) );
}
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
</quote>
I think the last line should actually have been
return ( throw_divide_by_zero( lhs.data / rhs.data ) );
Maybe a copy and paste error?
Anyway, using that template instead of built in arithmentic types, the
programmer is protected against divide-by-zero. If you try and divide
by zero, before you get to any use of the / operator on built in types,
the overloaded operator/ in Kai-Uwe's class detects the situation and
throws a C++ exception *INSTEAD OF* attempting to divide a built in
arithmetic type by zero.
Gavin Deane
Andre Kostur wrote:
>
"Arithmetic FUBAR"
That fits very nicely with division-by-zero :-)
Usenet threads take on a life of their own... regardless of the
originator's wishes.
What can be said in the face of such truth.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Zorro wrote:
>
Kai-Uwe Bux wrote:
>Grizlyk wrote:
Simon G Best wrote:
[snip]
>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.
That is not entirely correct: you can write a wrapper template for the
arithmetic types. I confine myself to a rough outline. Also, I will
acknowledge that it is impossible to make such wrappers behave exactly
like the built in types (e.g., with regard to automatic promotions and
conversions). However, in many cases, such a wrapper can be used. E.g.,
for debugging pointers, I do use a smart pointer whose operator* method
does assert( underlying_pointer != 0 ).
#include <stdexcept>
#include <string>
struct divide_by_zero : public std::out_of_range {
divide_by_zero ( std::string const & msg )
: std::out_of_range( msg )
{}
}; // divide_by_zero
template < typename ArithmeticType >
struct throw_divide_by_zero {
typedef ArithmeticType base_type;
explicit
throw_divide_by_zero ( base_type x = 0 )
: data ( x )
{}
friend
throw_divide_by_zero operator+ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
// many more friends
// ...
// and finally, division:
friend
throw_divide_by_zero operator/ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
if( rhs.data == 0 ) {
throw ( divide_by_zero( std::string( "division by 0" ) ) );
}
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
private:
base_type data;
}; // throw_divide_by_zero
#include <iostream>
int main ( void ) {
try {
throw_divide_by_zero<inta ( 0 );
throw_divide_by_zero<intb ( 3 );
b / a;
}
catch ( divide_by_zero const & c ) {
std::cout << c.what() << '\n';
}
}
Best
Kai-Uwe Bux
Kai-Uwe, this is nice. However, look at all the code you have written
for something so simple. And you also expect everyone to remember how
to do such things in all cases, possibly in complex situations?
If you have a need for this kind of thing, you write it once and the you
just use it. I do that for pointers. You do not need to re-implement that
every time. That's what library solutions are like.
Another advantage is the flexibility: if I regarded division by 0 a bug, I
could use an assert instead of a throw. I could even make that a policy
passed as a template parameter. If you put a mechanism into the core
language, you have a "one-size-fits-all" approach.
I am not entering the discussion.
We shall see about that. It appears a though you might have something to
say.
I was just wondering if you thought about your extensive creativity.
There is nothing extensive about the creativity in the code sample shown
above. The problem is fairly straight forward: the built-in types of C++
make virtually no guarantees towards enforcing preconditions of operations.
Thus, if you need types that do, you have to provide them yourself. That is
where the extensible type system of C++ comes in as the tool that the
language provides to help with these issues.
Other languages are designed differently. They may provide different means
of writing safe code. It is, however, not fair to claim that C++ does not
provide tools/mechanisms to ease safe coding.
Best
Kai-Uwe Bux
Zorro wrote:
>
Thanks to all comments, and in particular yours (to my blogger) I
realized I had made a slieght error because multiple compilers gave me
the same result (on Windows). My apologies. However ...
:-)
I have redone the blogger, and the article to show the disadvantages of
C++ exception model, and a better way of doing things. Looking at your
comment (above) I do not see what you are really trying to say. What do
you mean by "C++ does not impose safety on the programmer". So, how
come you cannot call a private method? It is the purpose of a modern
language to help with the safety.
The programmer is not obliged to use the private: label. The programmer
could define classes as structs, and leave everything public, for
example. C++ does not impose privacy, but provides it as a tool that
the programmer can use to discourage (quite possibly unsafe) breaches of
intended encapsulation. So, actually, private: is a very good example
of how C++ provides tools for safety without imposing safety.
Now, reread the article, without prejudice. I love C++ and I have known
it from the time before it was called C++. My argument is that,
someone's weak implementation techniques were forced into standard, and
your generation simply takes that as a religion.
You still don't seem to understand C++ :-(
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Zorro wrote:
Kai-Uwe, this is nice. However, look at all the code you have
written for something so simple.
There is one thing to keep in mind IMHO: C++ was designed to be a
_portable_ _systems_ language.
Even though it is close to the metal, it has to be the least common
denominator of all architectures it is intended to run on. Platform-
specific CPU exceptions clearly are not part of this "least common
denominator".
And no, handling a platform-specific exceptions like a division by
zero (or an access violation, for instance) is _not_ simple when you
consider that C++ can be implemented on platforms ranging from a 8-bit
68xx microcontroller up to the fastest supercomputers, with the x86
lying somewhere in the middle...
No wonder such a "trivial" task can take a few dozen lines to be
addressed correctly using only _standard_ C++...
Cheers,
--
IR
"Ian Collins" <ia******@hotmail.comwrote in message
news:51*************@mid.individual.net...
Zorro wrote:
No language can ever be completely safe. The intent is to move towards
a safer language, just as the introduction of "class" made a better C.
So now, all I am saying about C++ exception is that, it was not
well-thought. There is no need to change to a different language. The
standard can take a closer look and re-evaluate the benefits of the
current model. At least we can point out to other ideas by citing other
languages. One can close his ears to any argument by continually
bringing up "overhead". So be it.
Overhead isn't the point at issue, differentiating between exceptions
thrown by the application and asynchronous events generated by the
operating environment is.
Overhead has some relevance here, since you could replace such events with
exceptions. I presume that the reason that division by zero, for example,
produces undefined behaviour rather than a guaranteed C++ exception is the
checking overhead that would be necessary to throw an exception. If I have a
tight loop that does nothing but divisions and my code ensures that a division
by zero will not occur, I do not want superfluous checking for zero before every
division. Zorro wants the language to be safer, but the cost of that safety is
more than programnmers would be willing to bear. Many people choose to use C or
C++ precisely because they are "close to the machine" and in most cases do no
more than the programmer asks.
DW
David W wrote:
Overhead has some relevance here, since you could replace such
events with exceptions. I presume that the reason that division by
zero, for example, produces undefined behaviour rather than a
guaranteed C++ exception is the checking overhead that would be
necessary to throw an exception.
As a side note, all platforms I have worked on use some kind of IRQ to
notify the system when such event occurs, so it has no runtime cost in
"normal" operation in such cases.
But I agree that it is different on some architectures, and that this
may be the very reason why the C++ standard considers CPU-specific
exceptions as UB.
Cheers,
--
IR
IR wrote:
>
As a side note, all platforms I have worked on use some kind of IRQ to
notify the system when such event occurs, so it has no runtime cost in
"normal" operation in such cases.
But the (operating) system then has to handle those events and can do so
in a variety of ways. How the system handles them depends on the
system. And then, to take advantage of such event handling, the
language implementation has to do so in a way that's compatible with the
system's way of doing things. And then, when it comes to the
corresponding language-level exceptions, there may well have to be the
accompanying overheads just to answer the question, "Has a system-level
exception been thrown this time?" So, even though such system-level
exceptions wouldn't be thrown most of the time, the overheads could
still be there every single time such a piece of code gets executed,
just in case a system-level exception does get thrown.
:-|
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Grizlyk wrote:
Simon G Best wrote:
>Grizlyk wrote:
>>Can not, divide by zero can happen not only for zero, try divide 0xffff
to 0x02, test it in debug
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.
Are you talking about arithmetic overflow, and the like? I'm still not
sure quite what you meant by "divide 0xffff to 0x02", but I had thought
you meant integer division.
>>But compiler easy can setup trap for the error and throw divide_by zero
exception.
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 :)
Divide-by-zero isn't always a possibility. Such errors don't always
have the possibility of occurring. Consider the following:-
int foo(int x) {
for (int i(1); i <= 10; ++i) // i can't ever be zero.
x /= i; // Can never be divide-by-zero.
return x;
}
Checking for divide-by-zero, or checking for such things as system-level
(non-C++) 'exceptions', would be needless overhead in such a function.
2. We must report ALL errors to apropriate handler. Always. It is not
"overhead".
It's needless overhead when there's no possibility of such errors occuring.
3. "Divide by zero" handled by CPU practicaly, already handled,
similarly "bad memory access". Do we throw in the cases or silently
call exit()?
No. Usually, the operating system will handle such events. How the
operating system handles them depends on the operating system itself -
and that's beyond the scope of the C++ standard, because it's outside
the C++ language. There are various ways in which an operating system
could respond to such an event. Some may just terminate the process
that caused the event - the process gets no say in the matter at all.
Some may send some sort of signal to the process - but that signal may
be asynchronous. There are other possibilities.
For a process to deal with all such events the way you want, it would
have to pre-empt such events on some systems (with overheads), check for
corresponding signals on some other systems (with overheads), and do
other stuff on yet other systems (which again may involve overheads).
Such overheads only make sense when there's a real possibility of such
events occurring, and when such events would need to be handled
properly. Having such overheads each and every time certain kinds of
operations get performed, 'just in case', would result in needless
overheads on those occasions when such operations can't possibly cause
such events anyway.
Instead, as usual, C++ lets the programmer decide whether or not such
overheads are needed, rather than imposing them on the programmer.
Lets programmer make selection. To do it, standard must allow for
programmer to make selection between "throw" or "not throw".
Indeed. That's what C++ does.
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.
What C++ does is it allows the following (if I remember the relevant
syntax correctly):-
// I'm assuming int a, b;.
try {
if (b == 0) throw bad_divide();
a /= b;
} catch(...) { /*...*/ }
That's nicely platform-independent and portable :-) Also, in those
cases where there's no possibility of divide-by-zero, the try-catch
stuff need not be included, as bad_divide() will never get thrown, and
there'll never be anything to catch - no needless overheads.
4. Not only "Divide by zero", all processable harware errors must be
processed as point 3. I think.
Does that include an asteroid, a Cheeky Girl, or Lembit Opik landing
abruptly on the computer?
>>It looks like " We do not want to process the error, and will try to
find a cause of it, if we will not find any, we will not process the
error also. Abtreten! " :)
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,
I understood the words :-) but not what you meant.
>Different operating systems deal with such things in different ways.
Yes, and C++ exceptions is one of the way to hide the differences.
Yes, indeed :-)
>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++.
Uh, yeah, I think :-)
>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.
The tools are there, but the programmer has to use them (as illustrated
above).
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Grizlyk wrote:
Kai-Uwe Bux wrote:
>>Grizlyk wrote:
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.
That is not entirely correct: you can write a wrapper template for the
arithmetic types.
No, we can not write wrapper, because "divide by zero" error rising in
CPU, out of C++ scope.
What you do is you pre-empt such divisions by zero from even occurring
in the first place. That's the sort of thing that the suggested
wrappers do. No need to handle signals (or whatever) from lower down.
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Simon G Best wrote:
IR wrote:
>
As a side note, all platforms I have worked on use some kind of IRQ to
notify the system when such event occurs, so it has no runtime cost in
"normal" operation in such cases.
But the (operating) system then has to handle those events and can do so
in a variety of ways. How the system handles them depends on the
system. And then, to take advantage of such event handling, the
language implementation has to do so in a way that's compatible with the
system's way of doing things. And then, when it comes to the
corresponding language-level exceptions, there may well have to be the
accompanying overheads just to answer the question, "Has a system-level
exception been thrown this time?" So, even though such system-level
exceptions wouldn't be thrown most of the time, the overheads could
still be there every single time such a piece of code gets executed,
just in case a system-level exception does get thrown.
:-|
--
Simon G Best
What happens if I mention Leader Kibo in my .signature?
Comments starting with David, IR and here Simon are all valid and quite
interesting. The focal point is made by Simon, that the run-time lib of
language must have some form of check, for instance, is a flag set
(This can be done efficiently, and is not as bad as it sounds).
However, the model that results from having run-time support is
interesting too. As statements are executed, should an exception occur,
there is no need to write a statement such as throw for it. Note that,
I did not say system exception, or exceptions defined by user, or
whatever. Generally, of course, a user will define exceptional states
unknown to the libraries, and must explicitly raise those exceptions
(do a throw). Nevertheless, there are always an array of well-known
exceptions that the libraries can support. That is where the price is
paid. Do we want the run-time to check, or do we want the compiler to
take charge in all cases. When we leave it to the compiler
(synchronous), run-time library will generally not need to be aware of
exceptions occuring below it because the system will abort it.
Without support from run-time libs, I do not believe there is a way to
support resumption.
So, one has to accept a language for its purpose. As pointed out in
your notes, C and C++ are system programming languages, and one expects
them to be efficient.
I hope this helps, and that I have not said something against C++.
Regards.
Erik Wikström wrote:
On Jan 15, 10:36 am, "Zorro" <zor...@comcast.netwrote:
Erik Wikström wrote:
On Jan 14, 9:39 pm, "Zorro" <zor...@comcast.netwrote:
Simon G Best wrote:
As usual, C++ does not impose safety on the programmer; instead, it
provides tools to help the programmer write safe code.
What do you mean by "C++ does not impose safety on the programmer".
So, how come you cannot call a private method? It is the purpose ofa
modern language to help with the safety.
Then you say "C++ provides tools ....". Does C not do that already?So
why use C++?
C++ does not impose safety on the programmer by not requiring that the
safety-features are used, you can write very unsafe code in C++ if you
choose to. But C++ does provide features (such as private) that enables
the user to write safe code (these kind of things are the tools Simon
was referring to).
--
Erik WikströmErik, I am not sure where you disagree with me. I understand what Simon
means by tools. Then, I am saying that the use of those tools imposes
restrictions (if you will). A C++ programmer not using C++ features is
a human decision. The language cannot impose upon you to use it one way
or the other. Finally, I am saying that, C has sufficient features to
be used safely. The conclusion I am drawing is that, the reason for
something like private is so you can avoid mistakes in a large program.
I admit I made it very brief, but that is what I meant.
I was only giving an answer to the question 'What do you mean by "C++
does not impose safety on the programmer"'.
--
Erik Wikström
My apologies for the misunderstanding on my part.
Regards.
Kai-Uwe Bux wrote:
Zorro wrote:
Kai-Uwe Bux wrote:
Grizlyk wrote:
Simon G Best wrote:
[snip]
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.
That is not entirely correct: you can write a wrapper template for the
arithmetic types. I confine myself to a rough outline. Also, I will
acknowledge that it is impossible to make such wrappers behave exactly
like the built in types (e.g., with regard to automatic promotions and
conversions). However, in many cases, such a wrapper can be used. E.g.,
for debugging pointers, I do use a smart pointer whose operator* method
does assert( underlying_pointer != 0 ).
#include <stdexcept>
#include <string>
struct divide_by_zero : public std::out_of_range {
divide_by_zero ( std::string const & msg )
: std::out_of_range( msg )
{}
}; // divide_by_zero
template < typename ArithmeticType >
struct throw_divide_by_zero {
typedef ArithmeticType base_type;
explicit
throw_divide_by_zero ( base_type x = 0 )
: data ( x )
{}
friend
throw_divide_by_zero operator+ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
// many more friends
// ...
// and finally, division:
friend
throw_divide_by_zero operator/ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
if( rhs.data == 0 ) {
throw ( divide_by_zero( std::string( "division by 0" ) ) );
}
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
private:
base_type data;
}; // throw_divide_by_zero
#include <iostream>
int main ( void ) {
try {
throw_divide_by_zero<inta ( 0 );
throw_divide_by_zero<intb ( 3 );
b / a;
}
catch ( divide_by_zero const & c ) {
std::cout << c.what() << '\n';
}
}
Best
Kai-Uwe Bux
Kai-Uwe, this is nice. However, look at all the code you have written
for something so simple. And you also expect everyone to remember how
to do such things in all cases, possibly in complex situations?
If you have a need for this kind of thing, you write it once and the you
just use it. I do that for pointers. You do not need to re-implement that
every time. That's what library solutions are like.
Another advantage is the flexibility: if I regarded division by 0 a bug, I
could use an assert instead of a throw. I could even make that a policy
passed as a template parameter. If you put a mechanism into the core
language, you have a "one-size-fits-all" approach.
I am not entering the discussion.
We shall see about that. It appears a though you might have something to
say.
I do, but I really meant what I said. This will take a long discussion.
>
I was just wondering if you thought about your extensive creativity.
There is nothing extensive about the creativity in the code sample shown
above. The problem is fairly straight forward: the built-in types of C++
make virtually no guarantees towards enforcing preconditions of operations.
Thus, if you need types that do, you have to provide them yourself. That is
where the extensible type system of C++ comes in as the tool that the
language provides to help with these issues.
Other languages are designed differently. They may provide different means
of writing safe code. It is, however, not fair to claim that C++ does not
provide tools/mechanisms to ease safe coding.
Perhaps more like "it can become better" as in future revisions of the
standard. In other words, the point of discussion is what else can be
done, rather than putting down C++. I doubt the current standard is end
of evolution for C++.
Regards.
>
Best
Kai-Uwe Bux
IR wrote:
Zorro wrote:
Kai-Uwe, this is nice. However, look at all the code you have
written for something so simple.
There is one thing to keep in mind IMHO: C++ was designed to be a
_portable_ _systems_ language.
Even though it is close to the metal, it has to be the least common
denominator of all architectures it is intended to run on. Platform-
specific CPU exceptions clearly are not part of this "least common
denominator".
And no, handling a platform-specific exceptions like a division by
zero (or an access violation, for instance) is _not_ simple when you
consider that C++ can be implemented on platforms ranging from a 8-bit
68xx microcontroller up to the fastest supercomputers, with the x86
lying somewhere in the middle...
No wonder such a "trivial" task can take a few dozen lines to be
addressed correctly using only _standard_ C++...
Cheers,
--
IR
This is a very good point.
Regards.
Gavin Deane wrote:
Zorro wrote:
Andre Kostur wrote:
However, you are confusing two different things. The "Arithmetic
Exception" is not an exception in the C++ sense of the word. If that error
message had read "Arithmetic FUBAR", would that help? Attempting to
"catch" this type of exception (directly) makes no sense at all.
>
I did not say "Arithmetic Exception" is any form of C++ exception.
Please note what I am saying.
Exceptions occur at various levels of a system (CPU, layers of OS).
Each layer, either can handle the problem, or passes it to the next
layer. Now, if you wish to handle "Arithmetic Exception" in C++, you
need to throw it within C++. But whether you do, or do not throw the
exception in C++, somewhere in the system the exception will be raised.
It is an exception, and is not a FUBAR. Just because it was not thrown
within a C++ program does not change it to a FUBAR.
Yes, it does. It seems to me reading this thread that your entire
question is based on coincidence. CPU designers have the concept of
what happens in awkward situations like divide by zero, and C++
programmers have the concept of what happens in responce to a throw
statement, and while those two concepts are utterly unrelated, both
groups of people (CPU designers and C++ programmers) happen to have
chosen the word "exception" to describe their concept.
If CPU designers had instead chosen the word "FUBAR" for their concept,
and C++ programmers had chosen the word "tadpole" for theirs, do you
really think your original question would have arisen?
Gavin Deane
Gavin, the original question was the result of an error. I have
apologized for that. I further appreciate the comments that stopped me
from making a bigger fool of myself by inferring from the behavior of
C++ compilers on a single operating system. The article was redone as a
result, thanks everyone.
About the term "exception", the CPU simply sets a bit (say the overflow
bit in an addition). Depending on the context, the operating system may
or may not consider the instruction as invalid. If it does, it will
raise what has become known as exception. That was done by programmers,
who at the time had to use assembly language (I have done a lot of it),
later C and now C++.
The issue really never was "division-by-zero". It was the jump made to
the catch point without a throw, and resulting in destructors not being
called. I was wrong in that, this had nothing to do with C++ standard.
As comments were made, I replied the best way I could to end the topic.
But it has taken its own life, as pointed out by one of the authors.
For instance, I had to say something about your comment, and I am
trying to stay out of what could take a long discussion.
Regards.
Gavin Deane wrote:
Grizlyk wrote:
No, we can not write wrapper, because "divide by zero" error rising in
CPU, out of C++ scope.
Have you missed the point? In C++, the built in arithmetic types
provide no protection against divide-by-zero.
Yes, you aree with me, that C++ does not provide any protection against
divide-by-zero. The couse of it
1. snow in California in 2004 year,
2. mongol invasion,
3. erathquake on Mars,
or something else
it does not matter for us, because we must write low-level error
handler for unknown target machine with C++ compiler, because C++ does
not do it for us.
No? see below.
But you snipped Kai-Uwe's code which showed
a wrapper template that included the following overloaded operator:
<quote>
friend
throw_divide_by_zero operator/ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
if( rhs.data == 0 ) {
throw ( divide_by_zero( std::string( "division by 0" ) ) );
}
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
</quote>
if( rhs.data == 0 )
I am repeating again - source of the exception is hardware (CPU), the
test (rhs.data == 0) _is not enough_.
lhs.data + rhs.data
Means ( lhs.data / rhs.data ) - do you want to divide without CPU?
In general, you need another special CPU or coprocessor in your system,
which will not generate "divide by zero" to use your wrapper.
Simon G Best wrote:
And this is answer for you too: http://groups.google.com/group/comp....940264e5e65ae9
Are you talking about arithmetic overflow, and the like? I'm still not
sure quite what you meant by "divide 0xffff to 0x02", but I had thought
you meant integer division.
Just write any file and post it to debug as I wrote or read any book
about ix86 asm and DIV opcode. When we are dividing short numbers, C++
compiler can extend operands to ensure, the only 0 gives the error, but
resorces of the CPU (or other CPU) is not unlimited.
1. "Divide by zero" in most cases is error, for result is not the same,
as expect programmer.
Divide-by-zero isn't always a possibility. Such errors don't always
have the possibility of occurring. Consider the following:-
Checking for divide-by-zero, or checking for such things as system-level
(non-C++) 'exceptions', would be needless overhead in such a function.
I can not understand metter of your objections and why "needless
overhead" will appear.
2. We must report ALL errors to apropriate handler. Always. It is not
"overhead".
It's needless overhead when there's no possibility of such errors occuring.
I can not understand metter of your objections and why reporting about
error is "needless overhead", especially if error checking is hardware.
3. "Divide by zero" handled by CPU practicaly, already handled,
similarly "bad memory access". Do we throw in the cases or silently
call exit()?
No. Usually, the operating system will handle such events.
No of course, OS can only protect other parts of system, from you and
your program, OS _can not_ resume your program after error. It is
evidently.
C language proposes "signals" mechanism as std library, but it is not
enough for C++ and does not garantee any except halt by error. I think.
How the
operating system handles them depends on the operating system itself -
and that's beyond the scope of the C++ standard, because it's outside
the C++ language.
"How the operating system handles" is really out of C++, but "how you
program will continue" is not, is not out of C++.
Lets programmer make selection. To do it, standard must allow for
programmer to make selection between "throw" or "not throw".
Indeed. That's what C++ does.
No, does not, because C++ had no std tools to control it.
>
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.
try {
if (b == 0) throw bad_divide();
"(b == 0)" is not enough to prevent "divide by zero" error.
That's nicely platform-independent and portable :-)
No
4. Not only "Divide by zero", all processable harware errors must be
processed as point 3. I think.
Does that include an asteroid, a Cheeky Girl, or Lembit Opik landing
abruptly on the computer?
What is "Cheeky Girl" or "Lembit Opik" or "abruptly" in other places?
If result of any operation is incorrect (overflow for example), in most
cases function will work with error. But in the case of "divide by
zero" all other perfectly working parts of program will be halted. It
will be much better if C++ will garantee, that program will not be halt
automaitcally on error like overflow.
I understood the words :-) but not what you meant.
This is allegory.
Grizlyk wrote:
Simon G Best wrote:
>>How the
operating system handles them depends on the operating system itself -
and that's beyond the scope of the C++ standard, because it's outside
the C++ language.
There's nothing an application can do if the operating environment
terminates it.
>
"How the operating system handles" is really out of C++, but "how you
program will continue" is not, is not out of C++.
>>>Lets programmer make selection. To do it, standard must allow for
programmer to make selection between "throw" or "not throw".
Indeed. That's what C++ does.
No, does not, because C++ had no std tools to control it.
You can't have standard tools to control something the application
cannot control.
--
Ian Collins.
Grizlyk wrote:
Gavin Deane wrote:
Grizlyk wrote:
No, we can not write wrapper, because "divide by zero" error rising in
CPU, out of C++ scope.
Have you missed the point? In C++, the built in arithmetic types
provide no protection against divide-by-zero.
Yes, you aree with me, that C++ does not provide any protection against
divide-by-zero. The couse of it
1. snow in California in 2004 year,
2. mongol invasion,
3. erathquake on Mars,
or something else
it does not matter for us, because we must write low-level error
handler for unknown target machine with C++ compiler, because C++ does
not do it for us.
No? see below.
>But you snipped Kai-Uwe's code which showed
a wrapper template that included the following overloaded operator:
<quote>
friend
throw_divide_by_zero operator/ ( throw_divide_by_zero lhs,
throw_divide_by_zero rhs ) {
if( rhs.data == 0 ) {
throw ( divide_by_zero( std::string( "division by 0" ) ) );
}
return ( throw_divide_by_zero( lhs.data + rhs.data ) );
}
</quote>
>if( rhs.data == 0 )
I am repeating again - source of the exception is hardware (CPU), the
test (rhs.data == 0) _is not enough_.
For integral types, the c++ standard guarantees that this test is enough:
division by any integer different from 0 is guaranteed to produce an
(implementation defined) result. For floating point arithmetic, life may be
harder.
>lhs.data + rhs.data
Means ( lhs.data / rhs.data ) - do you want to divide without CPU?
Again, for integer types, the above line is guaranteed to work by the
standard provided rhs.data is a legal value != 0.
In general, you need another special CPU or coprocessor in your system,
which will not generate "divide by zero" to use your wrapper.
No you don't. All you need is a standard compliant compiler. Should the CPU
do something funny when you divide 10 by 3 the compiler would have to work
around this in order to be standard compliant.
I concede that (depending on the platform) there can be bit patterns that do
not represent legal values for signed integer types. You just have to write
the wrapper class so that it guarantees as an invariant that the underlying
integer data will never be invalid. This will require adding overflow
detection for +,-, and *. For unsigned integer types, all bit patterns are
valid values and these measures are unnecessary.
Best
Kai-Uwe Bux
Ian Collins wrote:
There's nothing an application can do if the operating environment
terminates it.
Most OS _never_ will terminate process on overflow, or any recoverable
error, but OS _never_ can resume process. C language declare "signals"
as interdace between OS and C, but signals is too simple for C++. C++
must support better processing for the errors, as C++ support
exceptions instead of return error value.
If OS will terminate process on overflow, it is concrete OS problem, as
DOS has no native threads suport, for example.
No, does not, because C++ had no std tools to control it.
You can't have standard tools to control something the application
cannot control.
Application can control.
Grizlyk wrote:
Ian Collins wrote:
>There's nothing an application can do if the operating environment
terminates it.
Most OS _never_ will terminate process on overflow, or any recoverable
error, but OS _never_ can resume process. C language declare "signals"
as interdace between OS and C, but signals is too simple for C++. C++
must support better processing for the errors, as C++ support
exceptions instead of return error value.
No. Signals are declared by the POSIX standard and have nothing to do with
a certain programming language.
Bjoern This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Daniel Wilson |
last post by:
I am having exception-handling and stability problems with .NET. I will
have a block of managed code inside try...catch and will still get a generic
..NET exception box that will tell me which...
|
by: Noor |
last post by:
please tell the technique of centralize exception handling without try catch
blocks in c#.
|
by: Master of C++ |
last post by:
Hi,
I am an absolute newbie to Exception Handling, and I am trying to
retrofit exception handling to a LOT of C++ code that I've written
earlier. I am just looking for a bare-bones, low-tech...
|
by: C# Learner |
last post by:
Some time ago, I remember reading a discussion about the strengths and
weaknesses of exception handling. One of the weaknesses that was put
forward was that exception handling is inefficient (in...
|
by: Ele |
last post by:
When Exception handling disabled compiler still spits out "C++ exception
handler used." Why is that?
Why does it ask for "Specify /EHsc"?
Thanks!
c:\Program Files\Microsoft Visual Studio...
|
by: Zytan |
last post by:
Ok something simple like int.Parse(string) can throw these exceptions:
ArgumentNullException, FormatException, OverflowException
I don't want my program to just crash on an exception, so I must...
|
by: George2 |
last post by:
Hello everyone,
Such code segment is used to check whether function call or exception-
handling mechanism runs out of memory first (written by Bjarne),
void perverted()
{
try{
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
