Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how to use long long and _ _ int64 in C++". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Long long and _ _ int64

The 64-bit int mentioned in C++ Primer has only long long, but in the actual various C++ compilers, 64-bit int has always had two standards. One is long long, and the other is _ _ int64. Non-mainstream VC even supports _ int64.

For the average C++ developer, this problem is not so important, because in actual development, the vast majority of cases using 32-bit int is enough. It is rare to go beyond the scope of int, but for algorithm players, this is a problem that must be considered. Because many topics will deliberately make the scope very large, examine the sensitivity of the players to the range of data.

We have a lot to discuss about long long and _ _ int64. Let's talk about it one by one.

2. Problems left over by history

First of all, let's talk about the background of this issue. why are there two standards? This is not that C++ 's standards are not stringent, or the major compilers are messing around, there is a problem left over from history.

Long long was first introduced by the C99 standard, but VC6.0 was introduced in 1998, before the C99 standard. So Microsoft came up with a variable called _ _ int64 to represent 64-bit integers. The first C++ compiler that many students use is VC6.0, so remember to use _ _ int64 instead of long long in VC6.0.

Now that VC6.0 has come up with _ _ int64, it is clear that subsequent C++ versions of Microsoft will have to be compatible with it. So in the win system, the variable type of this _ _ int64 has been used all the time. Of course, due to the update of C++ standard, of course the latest visual studio already supports long long.

GCC is not based on the windows system and naturally supports long long. Some other IDE under the win platform, such as dev C++ and CodeBlocks, also support long long because they also support _ _ int64 for compatibility with Microsoft systems. So a relatively simple way to distinguish is to determine whether the operating system the compiler is running is windows, and if it is windows, use _ _ int64, otherwise use long long.

3. The choice of cin, cout, scanf and printf.

This problem is also not a problem for C++ development engineers, there is no need for any choice, brainless with cin, cout is done. But for algorithmic competition players, this is still a problem to consider.

Because in the algorithm competition, especially when the amount of data is very large, the time occupied by read-in and output is very considerable. It seems to be the difference between cin cout and scanf and printf, but the performance of the two is very different.

I have done experiments, and with the same data, the efficiency of using scanf and printf is about ten times higher than that of cin and cout. Of course, there is no difference when the amount of data is small, but the impact is very great when the amount of data is very large. It is likely to lead to the same problem, the same algorithm, others passed, but we timed out.

There are two main explanations for the differences in performance. One explanation is that cin is always synchronized with stdin in order to mix with scanf without worrying about pointer confusion, coupled with binding. It is this step that consumes a lot of time. By the same token, cout will have similar problems. The second explanation is that cout will store the content to be output in the cache before output, and one more step in the middle will also lead to performance degradation.

With regard to the cost of synchronizing cin with stdin, we can solve it by adding this line of code:

Std::ios::sync_with_stdio (false)

This line of code means that canceling the pointer synchronization of cin, cout, stdin and stdout will greatly improve the performance of cin and cout to the same extent as scanf and printf. Of course, a better way is to use scanf and printf instead.

Another problem with using scanf and printf is that they are the standard input and output methods of the C language, and you need to provide identifiers to represent the type of variables, so the question is, what are the identifiers for long long and _ _ int64?

As a matter of fact, we can see at a glance that the identifier of long long is lld, so we use scanf to read in a number of type long long and write it as:

Long long a Tanf ("% lld", & a)

The identifier of _ _ int64 is I64d. Note that this is uppercase I, not l.

_ _ int64 ascape scanf ("% I64d", & a)

But there is a big pothole, and as mentioned earlier, compilers on the windows platform are already compatible with long long types. But even so, in versions prior to 2013, we still used% I64d for output, because the msvcrt.dll library provided by Microsoft only supports% I64d. It is equivalent to cutting off the possibility of using% lld output from the bottom. Microsoft fixed this problem in 2013 by adding support for% lld.

So a relatively simple way to distinguish is to look at the operating system, if it is a windows system, then all the use of _ _ int64 must be correct. If it is a linux or Mac system, then uniformly use long long.

I found the summary table made by the god on the Internet. I can also refer to the following table directly:

Variable definition output mode gcc (mingw32) Gmail + (mingw32) gcc (linux i386) Gmail + (linux i386) MicrosoftVisual C++ 6.0long long "% lld" error correct correct error unable to compile long long "% I64d" correct error unable to compile _ _ int64 "lld" error error unable to compile error _ _ int64 "% i64d" correct unable to compile correct unable to compile correct long longcout non-C++ correct non-C++ correct unable to compile Translation _ _ int64cout is not correct for C++, not C++ can not compile, cannot compile long longprintint64 () correctly cannot compile "how to use long long and _ _ int64 in C++", that's it. Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.