okay in that context i am thinking that perhaps you mean MSYS. is that what you mean? i did not know mingw actually distributed anything other that zip archives.
anyway, those are compiled and run from cmd.exe not from the msys shell. (if that is what you mean.) using the msys shell has no difference here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some months ago MinGW started using an installer that operates somewhat analagously to how the djgpp installer worked, you tell it what you want to do and then it goes and gets what you need, as opposed to the old way of just download one file, that, one the scale of Cygwin anyway, was not that big.
I included the fact that I ran my experiments in the MSYS rxvt window simply for completeness. (Or obfuscation, take your pick)
Wayne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
compiling with gcc from my own build but linking with libs from devcpp resulted in 24. compiling with gcc from devcpp and linking against my own builds resulted in 24.
this is weird.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I compiled the op's program and got the following messages:
C:/SoftDev/Projects/CppC/Misc/temp.cpp:40: call of overloaded `pow(int&, int&)' is ambiguous
C:/MinGW/include/math.h:165: candidates are: double pow(double, double)
C:/MinGW/include/c++/3.2.3/cmath:427: long double std::pow(long double, int)
C:/MinGW/include/c++/3.2.3/cmath:423: float std::pow(float, int)
C:/MinGW/include/c++/3.2.3/cmath:419: double std::pow(double, int)
C:/MinGW/include/c++/3.2.3/cmath:410: long double std::pow(long double, long double)
C:/MinGW/include/c++/3.2.3/cmath:401: float std::pow(float, float)
Execution terminated
Changed type of variable a, b, c to double and got a clean compile and the correct result.
Ray
Dev-C++ v4.9.9.2
gcc v3.2.3
Windows XP
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
that code uses three casts from different precisions nothing in the standard would require it to produce the same or even similar results. whats the big deal? depending on what options you pass to the compiler pow may not even be called and depending on the compiler no function may be called at all.
for fun: compiling the code as is with g++ on my machine produces a 24. compiling with O2 produced 25 with O3 the call was omited and the compiler handled it. changing the code to use cmath from the c++ standard results in 25 with no options or with any options and the result with no options a function other than pow was called. compiling the code after adding casts changed nothing. changing the code so that no variables and math.h was used without casts resulted in a 0 with any options and with casts produced the same results as the code with the variables. compiling with gcc had the exact same effect as g++, which makes sense, except for the case where i used cmath simply because it will not compile with gcc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-01-21
It is nonsense, because it is none not most.
The post I was quoting from does not contain a link. Since you are an anonymous user who does not sign your posts, how am I supposed ot know what link you are referring to?
The link I presume you are referring to from Herb Sutter does not prove yopur point at all. It simply says that for a double precision value N where N <= 1e8, N-1 will never be equal to N. That does not mean that N will always be an exact integer. It is a point about the granularity of the representation: When the exponent is large a single binary increment in the mantissa may be greater than 1.0 decimal. This is true for relatively small exponents in float types, hence the results in the example.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-01-21
...52bit mantissa... I think I'll stop digging. ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see some people telling that this is the problem with pow(). Well, Dev-C++ uses the win32 version of the gcc compiler right???
Well, I have gcc at home in Fedora Core 4 and in my college we have a "Net Lab" where there are Red Hat Linux and PCQ Linux. I tried in all of the gcc in them. All of them gave 25 except Dev-C++. So, what more reason do I need to put the blame on Dev C++???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried this with DevStudio 97 (VC++ 5.0) and the answer comes out 25.
I tried it with mingw 3.3.1 and the answer comes out 24.
This does not mean a problem with mingw, a lot depends on how the floating point numbers are handled.
In this case (yes, I dug into the assembly language and traced the state of the floating point control register).
When VC++ converts the floating point result from pow() back into an integer - it sets the mode of the x87 control register to ROUND UP.
When mingw converts the floating point result from pow() back to an integer, it sets the mode of the x87 register to CHOP.
Otherwise both produce reasonably similar assembly listings. The only difference is that mingw does the conversion with some assembly language instructions. VC++ calls a function called ftol() which does the conversion.
rr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-01-22
Interesting results. It follows therefore that the result of pow() in the MinGW case at least was not an exact integer as has been suggested (and I have conceded) it could be.
I did a little research, and it is an ISO C requirement (presumably C++ too) that conversion to an int is a truncating operation, so in that respect at least VC++ is non-compliant (even if more helpful). I admit I have not consulted the ISO standard directly but am relying on this article: http://mega-nerd.com/FPcast/ - see 4th paragraph in the 'Analysis' section.
Reading that article, it is possible that VC++'s action is an optimisation, since ROUND UP is the required mode for arithmentic operations, not having to switch modes for conversion saves time. The 'fast conversion' macro he presents is ten times faster that the compiler generated ISO cast!
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i said that doubles can represent exactly many integers. i never said that the pow function would work out exactly for integers. infact, if you cared to read, i said, before anyone else, that the problem here was the way pow is implemented. pow could be implemented in such a way that for exact integers the function would return an exact integer on machines that had doubles that do exactly represent integers. i never said that it would handle things in such a way. later ian added that it was more likely the way the fpu was being handled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-01-22
Woah! Calm down. I never said that you did say that (or at least that is not how what I said should be interpreted). I was merely suggesting that the value 25.0 could be exactly represented, so potentially pow() could work precisely in this instance at least.
I too suggested earlier that apart from the ability to exactly represent an integer (the part I was conceding), that errors may arise from both pow() and the conversion to int - so if you 'would care to read'...
Since you persist in refusing to sign your posts or log-in of course, I would not actually know what to read in anycase. I admit that I seldom read all the posts. Signing is a good idea; if you know what you are talking about,- and you seem to - it is easier to sort out the random drivel from the good stuff.
It seems that you are determined to pick an argument when we are in fact in agreement (misunderstanding perhaps, but agreement nonetheless).
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What versions of GCC are you using on the Linux boxes? Did you use the same test cases on all systems, including Dev-C++? There may be more more to it than meets the eye, especially since GCC 4.x has been released and stabilised whereas MinGW's stable and the GCC that Dev-C++ uses is still 3.x
Benjamin Lau
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-01-21
MinGW/GCC uses the Microsoft MSVCRT.DLL for its C runtime library rather than glibc, so to test if pow() is at fault, you would have to compile it with MSVC++ 6.0
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
$ splint.exe main.c
main.c: (in function main)
main.c:23:18: Function pow expects arg 1 to be double gets int: int_a
To allow all numeric types to match, use +relaxtypes.
main.c:23:25: Function pow expects arg 2 to be double gets int: int_b
main.c:23:5: Assignment of double to int: int_c = pow(int_a, int_b)
main.c:27:5: Assignment of double to float: float_c = pow(float_a, float_b)
main.c:35:20: Function pow expects arg 1 to be double gets int: int_a
main.c:35:27: Function pow expects arg 2 to be double gets int: int_b
main.c:35:5: Assignment of double to float: float_c = pow(int_a, int_b)
main.c:39:21: Function pow expects arg 1 to be double gets int: int_a
main.c:39:28: Function pow expects arg 2 to be double gets int: int_b
main.c:43:20: Function pow expects arg 1 to be double gets int: int_a
main.c:43:27: Function pow expects arg 2 to be double gets int: int_b
main.c:43:5: Assignment of double to float: float_c = pow(int_a, int_b)
main.c:47:21: Function pow expects arg 1 to be double gets int: int_a
main.c:47:28: Function pow expects arg 2 to be double gets int: int_b
main.c:53:24: Function pow expects arg 1 to be double gets int: int_a
main.c:53:31: Function pow expects arg 2 to be double gets int: int_b
main.c:59:22: Function new_pow expects arg 1 to be double gets int: int_a
main.c:59:29: Function new_pow expects arg 2 to be double gets int: int_b
main.c:59:5: Assignment of double to int: int_c = new_pow(int_a, int_b)
pb
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Compiling...
Main.c
c:\temp\tset\main.c(23) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
c:\temp\tset\main.c(27) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data
c:\temp\tset\main.c(35) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data
c:\temp\tset\main.c(43) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data
c:\temp\tset\main.c(59) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
$ main.exe
c = pow(a,b)
int a,b,c: 25
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 25
c = (int) pow(a,b)
int a,b,c: 25
c = new_pow(a,b)
int a,b,c: 25
pb
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, in case anyone is curious as to what the respective standards actually say with respect to what Clifford wrote....
From the C Standard, ISO/IEC 9899:1999, section 6.3.1.4:
When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.
From the C++ Standard, ISO/IEC 14882:2003, section 4.9:
An rvalue of a floating point type can be converted to an rvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type. [Note: If the destination type is bool, see 4.12. ]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am running a somewhat older version of MinGW on this computer - i have not taken to the new installation process that MinGW has moved to...
Wayne
okay in that context i am thinking that perhaps you mean MSYS. is that what you mean? i did not know mingw actually distributed anything other that zip archives.
anyway, those are compiled and run from cmd.exe not from the msys shell. (if that is what you mean.) using the msys shell has no difference here.
Some months ago MinGW started using an installer that operates somewhat analagously to how the djgpp installer worked, you tell it what you want to do and then it goes and gets what you need, as opposed to the old way of just download one file, that, one the scale of Cygwin anyway, was not that big.
I included the fact that I ran my experiments in the MSYS rxvt window simply for completeness. (Or obfuscation, take your pick)
Wayne
One more note of comparison. Compiling and running this code in CodeBlocks (rc2) gives the incorrect 24. Very interesting.
Wayne
compiling with gcc from my own build but linking with libs from devcpp resulted in 24. compiling with gcc from devcpp and linking against my own builds resulted in 24.
this is weird.
using 4.9.8.0 I had to add some casts to get the code to compile without warnings
I ended up with:
include <stdio.h>
include <stdlib.h>
include <math.h>
int main(int argc, char *argv[])
{
int a=5, b=2, c;
c=(int)pow((float)a,b);
printf("%d\n",c);
system("PAUSE");
return 0;
}
which gave the answer as 25
b_a
I compiled the op's program and got the following messages:
C:/SoftDev/Projects/CppC/Misc/temp.cpp:40: call of overloaded `pow(int&, int&)' is ambiguous
C:/MinGW/include/math.h:165: candidates are: double pow(double, double)
C:/MinGW/include/c++/3.2.3/cmath:427: long double std::pow(long double, int)
C:/MinGW/include/c++/3.2.3/cmath:423: float std::pow(float, int)
C:/MinGW/include/c++/3.2.3/cmath:419: double std::pow(double, int)
C:/MinGW/include/c++/3.2.3/cmath:410: long double std::pow(long double, long double)
C:/MinGW/include/c++/3.2.3/cmath:401: float std::pow(float, float)
Execution terminated
Changed type of variable a, b, c to double and got a clean compile and the correct result.
Ray
Dev-C++ v4.9.9.2
gcc v3.2.3
Windows XP
Ray,
Out of curiosity, did you compile that as C or C++?
Wayne
that code uses three casts from different precisions nothing in the standard would require it to produce the same or even similar results. whats the big deal? depending on what options you pass to the compiler pow may not even be called and depending on the compiler no function may be called at all.
for fun: compiling the code as is with g++ on my machine produces a 24. compiling with O2 produced 25 with O3 the call was omited and the compiler handled it. changing the code to use cmath from the c++ standard results in 25 with no options or with any options and the result with no options a function other than pow was called. compiling the code after adding casts changed nothing. changing the code so that no variables and math.h was used without casts resulted in a 0 with any options and with casts produced the same results as the code with the variables. compiling with gcc had the exact same effect as g++, which makes sense, except for the case where i used cmath simply because it will not compile with gcc.
Wayne, I compiled it using C++.
Ray
It is nonsense, because it is none not most.
The post I was quoting from does not contain a link. Since you are an anonymous user who does not sign your posts, how am I supposed ot know what link you are referring to?
The link I presume you are referring to from Herb Sutter does not prove yopur point at all. It simply says that for a double precision value N where N <= 1e8, N-1 will never be equal to N. That does not mean that N will always be an exact integer. It is a point about the granularity of the representation: When the exponent is large a single binary increment in the mantissa may be greater than 1.0 decimal. This is true for relatively small exponents in float types, hence the results in the example.
Clifford
...52bit mantissa... I think I'll stop digging. ;-)
I see some people telling that this is the problem with pow(). Well, Dev-C++ uses the win32 version of the gcc compiler right???
Well, I have gcc at home in Fedora Core 4 and in my college we have a "Net Lab" where there are Red Hat Linux and PCQ Linux. I tried in all of the gcc in them. All of them gave 25 except Dev-C++. So, what more reason do I need to put the blame on Dev C++???
I've tried this with DevStudio 97 (VC++ 5.0) and the answer comes out 25.
I tried it with mingw 3.3.1 and the answer comes out 24.
This does not mean a problem with mingw, a lot depends on how the floating point numbers are handled.
In this case (yes, I dug into the assembly language and traced the state of the floating point control register).
When VC++ converts the floating point result from pow() back into an integer - it sets the mode of the x87 control register to ROUND UP.
When mingw converts the floating point result from pow() back to an integer, it sets the mode of the x87 register to CHOP.
Otherwise both produce reasonably similar assembly listings. The only difference is that mingw does the conversion with some assembly language instructions. VC++ calls a function called ftol() which does the conversion.
rr
Interesting results. It follows therefore that the result of pow() in the MinGW case at least was not an exact integer as has been suggested (and I have conceded) it could be.
I did a little research, and it is an ISO C requirement (presumably C++ too) that conversion to an int is a truncating operation, so in that respect at least VC++ is non-compliant (even if more helpful). I admit I have not consulted the ISO standard directly but am relying on this article: http://mega-nerd.com/FPcast/ - see 4th paragraph in the 'Analysis' section.
Reading that article, it is possible that VC++'s action is an optimisation, since ROUND UP is the required mode for arithmentic operations, not having to switch modes for conversion saves time. The 'fast conversion' macro he presents is ten times faster that the compiler generated ISO cast!
Clifford
i said that doubles can represent exactly many integers. i never said that the pow function would work out exactly for integers. infact, if you cared to read, i said, before anyone else, that the problem here was the way pow is implemented. pow could be implemented in such a way that for exact integers the function would return an exact integer on machines that had doubles that do exactly represent integers. i never said that it would handle things in such a way. later ian added that it was more likely the way the fpu was being handled.
Woah! Calm down. I never said that you did say that (or at least that is not how what I said should be interpreted). I was merely suggesting that the value 25.0 could be exactly represented, so potentially pow() could work precisely in this instance at least.
I too suggested earlier that apart from the ability to exactly represent an integer (the part I was conceding), that errors may arise from both pow() and the conversion to int - so if you 'would care to read'...
Since you persist in refusing to sign your posts or log-in of course, I would not actually know what to read in anycase. I admit that I seldom read all the posts. Signing is a good idea; if you know what you are talking about,- and you seem to - it is easier to sort out the random drivel from the good stuff.
It seems that you are determined to pick an argument when we are in fact in agreement (misunderstanding perhaps, but agreement nonetheless).
Clifford
no i did misunderstand that to be saying that my statement had been wrong. if that is not that case sorry for the confusion on my part.
What versions of GCC are you using on the Linux boxes? Did you use the same test cases on all systems, including Dev-C++? There may be more more to it than meets the eye, especially since GCC 4.x has been released and stabilised whereas MinGW's stable and the GCC that Dev-C++ uses is still 3.x
Benjamin Lau
MinGW/GCC uses the Microsoft MSVCRT.DLL for its C runtime library rather than glibc, so to test if pow() is at fault, you would have to compile it with MSVC++ 6.0
Clifford
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x
--enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization
--enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
$ gcc -ansi -Wall -pedantic main.c -o g-test
$ g-test.exe
c = pow(a,b)
int a,b,c: 25
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 25
c = (int) pow(a,b)
int a,b,c: 25
c = new_pow(a,b)
int a,b,c: 25
$ gcc -ansi -Wall -pedantic -O2 main.c -o g-test-o2
$ g-test-o2.exe
c = pow(a,b)
int a,b,c: 25
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 25
c = (int) pow(a,b)
int a,b,c: 25
c = new_pow(a,b)
int a,b,c: 25
$ gcc -ansi -Wall -pedantic -mno-cygwin main.c -o nog-test
$ nog-test.exe
c = pow(a,b)
int a,b,c: 24
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 25
c = (int) pow(a,b)
int a,b,c: 24
c = new_pow(a,b)
int a,b,c: 25
$ gcc -ansi -Wall -pedantic -mno-cygwin main.c -O2 -o nog-test-o2
$ nog-test-o2.exe
c = pow(a,b)
int a,b,c: 24
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 24
c = (int) pow(a,b)
int a,b,c: 24
c = new_pow(a,b)
int a,b,c: 24
$ gcc -v
Reading specs from d:/dev-cpp/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
$ gcc -ansi -Wall -pedantic main.c -o test
$ test.exe
c = pow(a,b)
int a,b,c: 24
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 25
c = (int) pow(a,b)
int a,b,c: 24
c = new_pow(a,b)
int a,b,c: 25
$ gcc -ansi -Wall -pedantic -O2 main.c -o test-o2
$ test-o2.exe
c = pow(a,b)
int a,b,c: 24
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 24
c = (int) pow(a,b)
int a,b,c: 24
c = new_pow(a,b)
int a,b,c: 24
$ cat -n main.c
1 #include <stdio.h>
2 #include <math.h>
3
4 static double new_pow (double a, double b);
5
6 int
7 main (void)
8 {
9 int int_a = 5;
10 int int_b = 2;
11 int int_c;
12
13 float float_a = 5.0;
14 float float_b = 2.0;
15 float float_c;
16
17 double double_a = 5.0;
18 double double_b = 2.0;
19 double double_c;
20
21 printf ("c = pow(a,b)\n");
22 {
23 int_c = pow (int_a, int_b);
24 printf ("int a,b,c: %d\n", int_c);
25 }
26 {
27 float_c = pow (float_a, float_b);
28 printf ("float a,b,c: %f\n", float_c);
29 }
30 {
31 double_c = pow (double_a, double_b);
32 printf ("double a,b,c: %f\n", double_c);
33 }
34 {
35 float_c = pow (int_a, int_b);
36 printf ("int a,b, float c: %f\n", float_c);
37 }
38 {
39 double_c = pow (int_a, int_b);
40 printf ("int a,b, double c: %f\n", double_c);
41 }
42 {
43 float_c = pow (int_a, int_b);
44 printf ("int a,b, (int)float c: %d\n", (int) float_c);
45 }
46 {
47 double_c = pow (int_a, int_b);
48 printf ("int a,b, (int)double c: %d\n", (int) double_c);
49 }
50
51 printf ("\nc = (int) pow(a,b)\n");
52 {
53 int_c = (int) pow (int_a, int_b);
54 printf ("int a,b,c: %d\n", int_c);
55 }
56
57 printf ("\nc = new_pow(a,b)\n");
58 {
59 int_c = new_pow (int_a, int_b);
60 printf ("int a,b,c: %d\n", int_c);
61 }
62
63 /
64 printf ("\nPress any key to continue...");
65 getch ();
66 printf ("\n");
67 /
68
69 return 0;
70 }
71
72 static double
73 new_pow (double a, double b)
74 {
75 double c;
76 c = pow (a, b);
77 return c;
78 }
$ splint.exe main.c
main.c: (in function main)
main.c:23:18: Function pow expects arg 1 to be double gets int: int_a
To allow all numeric types to match, use +relaxtypes.
main.c:23:25: Function pow expects arg 2 to be double gets int: int_b
main.c:23:5: Assignment of double to int: int_c = pow(int_a, int_b)
main.c:27:5: Assignment of double to float: float_c = pow(float_a, float_b)
main.c:35:20: Function pow expects arg 1 to be double gets int: int_a
main.c:35:27: Function pow expects arg 2 to be double gets int: int_b
main.c:35:5: Assignment of double to float: float_c = pow(int_a, int_b)
main.c:39:21: Function pow expects arg 1 to be double gets int: int_a
main.c:39:28: Function pow expects arg 2 to be double gets int: int_b
main.c:43:20: Function pow expects arg 1 to be double gets int: int_a
main.c:43:27: Function pow expects arg 2 to be double gets int: int_b
main.c:43:5: Assignment of double to float: float_c = pow(int_a, int_b)
main.c:47:21: Function pow expects arg 1 to be double gets int: int_a
main.c:47:28: Function pow expects arg 2 to be double gets int: int_b
main.c:53:24: Function pow expects arg 1 to be double gets int: int_a
main.c:53:31: Function pow expects arg 2 to be double gets int: int_b
main.c:59:22: Function new_pow expects arg 1 to be double gets int: int_a
main.c:59:29: Function new_pow expects arg 2 to be double gets int: int_b
main.c:59:5: Assignment of double to int: int_c = new_pow(int_a, int_b)
pb
Default MSVC 6 Debug Configuration
Compiling...
Main.c
c:\temp\tset\main.c(23) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
c:\temp\tset\main.c(27) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data
c:\temp\tset\main.c(35) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data
c:\temp\tset\main.c(43) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data
c:\temp\tset\main.c(59) : warning C4244: '=' : conversion from 'double ' to 'int ', possible loss of data
$ main.exe
c = pow(a,b)
int a,b,c: 25
float a,b,c: 25.000000
double a,b,c: 25.000000
int a,b, float c: 25.000000
int a,b, double c: 25.000000
int a,b, (int)float c: 25
int a,b, (int)double c: 25
c = (int) pow(a,b)
int a,b,c: 25
c = new_pow(a,b)
int a,b,c: 25
pb
Well, in case anyone is curious as to what the respective standards actually say with respect to what Clifford wrote....
From the C Standard, ISO/IEC 9899:1999, section 6.3.1.4:
When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.
From the C++ Standard, ISO/IEC 14882:2003, section 4.9:
An rvalue of a floating point type can be converted to an rvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type. [Note: If the destination type is bool, see 4.12. ]