Confusing compile error

[Richard Herring]

But I suspect it has to do with me dabbling with how to implement member
functions and I simply used Complex numbers and magnitude as an obvious
example. However I, personally, would never label such a function "abs()"
since sqrt( re*re + im*im );is called the "modulus" in math circles.

When it isn't called the "absolute value", of course. "Modulus" has
other meanings too.

http://mathworld.wolfram.com/AbsoluteValue.html
http://mathworld.wolfram.com/Modulus.html

The authors of the Holy C++ Standard chose to call their family of
functions abs(). If you don't like it, take it up with them.

 

[Pmb]

[ Posted & e-mailed to Pete ( PMB ) ]

Hi Richard Herring, ( and Pete )

Re: Your complex x ( 0.0, 1e35 );

Are you hinting that one should use double variables ?

Or are you saying that you should check for overflows ?

Either way,
I don't think that was Pete's main concern at this point.

As you yourself said, your remarks are,
" worth every penny [ Pete ] paid for them. "

He seems to think that, given the complex number z = x + i y, that its worth
testing as to whether x = 0 or y = 0 since then the modulus is either the
magnitude of x ( i y = 0) or the magnitude of y (if x = 0). However that
requires testing whether a floating point number is zero. In all numerical
applications that I can think of which use complex numbers such a test is a
waste of time. One should never test to see if a floating point number is
zero.It is quite unlikely that a complex number is either purely real of
purely imaginary. At least in all applications that come to mind. It simply
isn't worth the test since the occasion will never come up when determining
the modulus of z.

This, of course, does not mean that one shouldn't test for division by zero.
That is something different from performance. That is a test to avoid a
runtime error.

Pmb

 

[Richard Herring]

[...]

One should never test to see if a floating point number is
zero.

[...]

This, of course, does not mean that one shouldn't test for division by zero.

!

 

[Richard Herring]

Hi Pete ( Pmb ), [ Posted & e-mailed ]

I was looking in <math.h> when I was this:

// Definition of a _complex struct
// to be used by those who use cabs ( );

That's provided for compatibility with C. C++ has better ways of
handling complex numbers.

// and want type checking on their argument

// real and imaginary parts
struct _complex { double x, y ; } ;

_CRTIMP double __cdecl _cabs ( struct _complex );

And your point was?

You won't find any of that specified in the C++ Standard.
You're not supposed to look inside standard header files ;-)

And in the help, I found this:

float, 4 bytes, no other name, 3.4E +/- 38 ( 7 digits )
double, 8 bytes, no other name, 1.7E +/- 308 ( 15 digits )

That's implementation-dependent, but not atypical.

 

[Jeff Relf]

Hi Pmb ( Pete ),

Re: Dividing by zero.

There are basically two ways to compile code:
1. For release, 2. For Debugging.

Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger.

So a Div_By_Zero never leaves the end-user high and dry.

 

[Pmb]

Hi Pmb ( Pete ),

Re: Dividing by zero.

There are basically two ways to compile code:
1. For release, 2. For Debugging.

Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger.

So a Div_By_Zero never leaves the end-user high and dry.

Compile and run the following
______________________________
#include <iostream.h>

int main()
{
int x, y, z;

x = 1;
y = -1;
z = 1/(x+y);

cout << "z = " << z << endl;

return 0;
}
______________________________

What do you get?

Pmb

 

[Richard Herring]

Hi Pmb ( Pete ),

Re: Dividing by zero.

There are basically two ways to compile code:
1. For release, 2. For Debugging.

Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger.

Where in the standard do you find that?

So a Div_By_Zero never leaves the end-user high and dry.

This is comp.lang.c++, where the topic is standard C++.

According to the standard, division by zero is undefined behaviour, up
to and including nasal demons.

 

[Jeff Relf]

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

 

[Karl Heinz Buchegger]

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

Your clients are unimportant for this group.

The question remains:
Where in the C++ standard is it mentioned that
dividing by 0 does not trigger an exception with
release compiled code.

Just because *your* compiler produces code that behaves
that way doesn't mean that this is so on all compilers.

 

[Phlip]

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

Wise programmers plan, just a little, for the future. The less
standard-compliant your code, the more likely it will break when you change
compiler vendors, or compiler versions, or even the compilation options.
This ensure clients may come back for more.

The C languages are "portable assembler". They provide a wide range of ways
to create "undefined behavior", meaning the compiler vendor is not required
to guarantee any particular result if a programmer crosses a very obvious
line. Things like double-deleting allocated memory, writing off the end of
an array, etc. Part of becoming proficient, and less than dangerous, in the
C languages is learning the complete list of undefined behaviors, and the
best practices that avoid them. That's what this newsgroup means each time
it slings out the loaded word "standard".

The fastest way to become non-proficient is to rely on "but my compiler
liked it". That attitude causes a skyrocketing rate of bugs, all
extraordinarily hard to detect and debug. Programmers who learn and follow a
sane subset don't get that problem.

 

[Jeff Relf]

Hi Pmb ( Pete ),

Re: Dividing by zero.

I was only referring to floating point math, not integers.

Try this ( Compile for release, not debug ):

float N = 1, D = 1, DD = -1 ; N /= ( D + DD );
char Output [ 88 ];
sprintf ( Output, "%3.3f", N );

In VC 6, Output becomes: 1.#IO,
it runs with no complaints, even in the debugger.
[ Note, _isnan( N ) will let you catch that overflow ]

When I change everything to integers:
In the debugger it throws an exception, outside it hangs.

But I also tried to compile this:

int i ; i /= 0 ;

Which caused this funny result:

C:\AA.CPP(253) : fatal error C1001: INTERNAL COMPILER ERROR
( compiler file 'E:\8168\vc98\p2\src\P2\main.c', line 506 )
Please choose the Technical Support
command on the Visual C++ Help menu,
or open the Technical Support help file
for more information

E:\8168\vc98\p2\src\P2\main.c ?

I don't have anything that looks like that.

 

[Richard Herring]

Hi Richard Herring,

I mentioned,
" Dividing by zero with release-complied code
will trigger no error, and no exceptions,
provided that you are not in the debugger. "

And you asked me,
" Where in the standard do you find that ? "

My clients are using my code, not your standards.

Then you're off-topic for this newsgroup.

 

[Jeff Relf]

Hi Karl Heinz Buchegger,

You asked,
" Where in the C++ standard is it mentioned that
dividing by 0 does not trigger an exception with
release compiled code. "

For VC 6 release-complied code,
a floating point divide-by-zero simply returns an overflow.
Which can then simply be checked using _isnan( float ).

I just checked integers ... They will hang your code ...
forcing you to kill it.

Now, ignoring standards for just one moment,
which response do you think was better behaved ?
A. The one that had to be killed by hand.
B. The one that simply returned an overflow,
and which could then be checked using _isnan( float ).

Take your time answering this question,
I know how hard it is for you.

After you answered that question,
I might answer your question
about IEEE floating point standards.

 

[Jeff Relf]

Hi Phlip,

Nothing is more undefined and nebulous
than a so-called standard.

Learn that buddy.

Coding is about testing, proving and then retesting.

... Standards ? Stop making me laugh.

 

[tom_usenet]

Hi Pmb ( Pete ),

Re: Dividing by zero.

I was only referring to floating point math, not integers.

Try this ( Compile for release, not debug ):

float N = 1, D = 1, DD = -1 ; N /= ( D + DD );
char Output [ 88 ];
sprintf ( Output, "%3.3f", N );

In VC 6, Output becomes: 1.#IO,
it runs with no complaints, even in the debugger.
[ Note, _isnan( N ) will let you catch that overflow ]

When I change everything to integers:
In the debugger it throws an exception, outside it hangs.

But I also tried to compile this:

int i ; i /= 0 ;

i is uninitialized, which means you shouldn't do anything to it except
assign it a value. Divide by 0 is always a bug, so don't do it.

Which caused this funny result:

C:\AA.CPP(253) : fatal error C1001: INTERNAL COMPILER ERROR
( compiler file 'E:\8168\vc98\p2\src\P2\main.c', line 506 )
Please choose the Technical Support
command on the Visual C++ Help menu,
or open the Technical Support help file
for more information

E:\8168\vc98\p2\src\P2\main.c ?

I don't have anything that looks like that.

I don't see a question in there. What's your question?

If you divide by 0, you get undefined behaviour. Exactly what happens
varies from compiler to compiler, platform to platform, and can depend
on compiler options. So best not to do it! Check denominators before
dividing...

You might want to ask over in microsoft.public.vc.language for VC
specific issues, such as ICEs.

Tom

 

[tom_usenet]

Hi Phlip,

Nothing is more undefined and nebulous
than a so-called standard.

Learn that buddy.

Coding is about testing, proving and then retesting.

... Standards ? Stop making me laugh.

Try upgrading to VC7.1 and you'll probably stop laughing when your
"tested" hacks stop working (since they relied on particular behaviour
of your current compiler) and have to be re-written. And so the cycle
continues when you upgrade to the next version...

If you write to standards, you'll find that testing goes a lot more
smoothly, and your code will work when compiled with a variety of
different compilers and versions.

Tom

 

[Phlip]

Hi Phlip,

Nothing is more undefined and nebulous
than a so-called standard.

Learn that buddy.

Coding is about testing, proving and then retesting.

... Standards ? Stop making me laugh.

Please please tell me you'l never program anything that flies over me.

 

[red floyd]

Try this ( Compile for release, not debug ):

My compiler has no "compile for release" option.

 

[Phlip]

My compiler has no "compile for release" option.

Then you won't get a VC++ "INTERNAL COMPILER ERROR".

;-)

 

[Jeff Relf]

Hi red floyd,

You said that your compiler,
' has no " compile for release " option. '

Why ? Is it the student version ?

Only the Pro version of VC 6 has the optimizer.