I did a water problem today, POJ-1004 , one water problem, 12 double-type numbers to calculate the average
but,
1 #include <iostream> 2 #include <cstdio> 3 using namespace std; 4 int main() { 5 double n; 6 while (cin>>n) { 7 int i=0; 8 double total = n; 9 while (i++<11) { 10 cin>>n; 11 total += n; 12 } 13 printf("$%.2lf\n", total/12); 14 } 15 return 0; 16 }
This seemingly flawless code turns out to be WA,
After WA twice, it's not a matter of code, it is submitted with GCC, G++, and C++ respectively. When it comes to C++, it is A! ! !
Summarize the summary to avoid repeat offenses
------------------------------------------------------------------------------------------------------------------------
First: G++ and GCC are compilers for C++ and C, respectively, and C++ and C are languages.
But the one on POJ indicates the compiler you need to submit the code to run. The compilers corresponding to C and C++ are the C and C++ compilers in VC++ 2008, while GCC and G++ correspond to the corresponding compilers.
Then I used both printf and cin above how to submit?
I saw a blog description: There is no difference in the code under the G++ and C++ options, but there is a certain gap between the two in the library. For example, G++ can cin a string variable by default, and when choosing C++, you need #include<string> , if the code is written in C++, it is best to choose G++ as the compiler when submitting.
Sorry, I don't use the string class, but G++ submits WA! ! !
The difference doesn't stop there.
------------------------------------------------------------------------------------------------------------------------
Why did G++ submit WA?
Okay back to reality. When I was doing poj 3122 yesterday, I encountered the embarrassing situation of G++WA; C++AC again.
why? In fact, this is also a part of the compiler optimization, that is, the precision default.
As we all know, the long long type, as a data type that is only recognized as a basic data type in C/C++11, is in different rings.
Under the circumstance, his type identifier is different. That is, we talk about %lld and %I64d. Similarly, the double type is also a
an interesting type. The double type is actually a double precision type, and its memory length is generally larger than that of the float type (single precision type)
The number is doubled, and sometimes double is called long float in the very early standard. So there is why the float type
Use %f, double use %lf. But since it is not the kind of memory that used to be a few megabytes, opening one more double will exceed the memory.
age, so double and float are automatically optimized in gcc.
When reading data with scanf, in order to distinguish it from float, use %lf.
When writing data with printf, double and float are essentially the same type, but the memory usage is different. They
The identifiers are all %f. Note that this is different from standard C, where all are %f.
Of course, although another special type, long double, is not commonly used, the compiler still supports it. Here is an episode, the theory
The long double should be twice the double (similar to the relationship between long long and int, because long and int are actually one thing)
. But in fact, long double is very strange, it is a 10-byte monster, he has two spare bytes, no matter how you change it, it will not be sent.
changing. Identifiers for input and output are all %Lf, uppercase L.
But here is another problem, why do I use %f to achieve WA locally, and use %f to AC on OJ?
Because if we use the IDE of Code::Blocks under Windows, the compiler is MinGW. thing
In fact, in order to maintain the cross-platform nature of gcc as much as possible, MinGW directly uses MSVC in some places, and the one that affects us the most.
That's the problem with the identifier. Simply put, if you want to test locally, then it is best to use the standard C identifier system
system; if you want to submit code, please change to the set of identifier system of gcc.
Then there is the problem of the compiler version. The current MinGW version has reached 4.8, but POJ still uses 4.4, so the lower version is compiled
The device also has some unusual problems.
Of course, there is a simpler method, which is to directly use the input and output streams to control the input and output, which is more convenient and has better cross-platform performance.
This kind of error because of the identifier does not occur.
The table looks like this:
The table looks like this:
| double f; | POJ G++ commit | POJ C++ commit | Native test (MinGW GCC 4.8) | safest way |
| enter | scanf(“%lf”, &f); | scanf(“%lf”, &f); | scanf(“%lf”, &f); | cin >> f; |
| output | printf(“%f“, f); | printf(“%lf”, f); | printf(“%lf“, f); | cout << f; |
------------------------------------------------------------------------------------------------------------------------
It turns out that there is still a problem of accuracy, so to summarize:
1. When using string, C++ needs to include header files: #include <string>, G++ does not need
2. Accuracy issues
3. Reminders for using GCC/G++:
For 64-bit integers, long long int and __int64 are both supported and equivalent. But only scanf("%I64d", ...) and printf("%I64d", ...) are supported for reading and writing .
"%lld" is not supported because the msvcrt.dll dynamic link library used by GCC and G++ under MinGW does not support the C99 standard.
According to the ISO C++ standard, under G++, the return value of the main function must be int, otherwise it will cause Compile Error (compile error) judgment
4. When G++/GCC uses scanf and printf, pay attention to quoting <stdio.h>/<cstdio>, only quoting <iostream> is not recognized