使用C ++将STDIN数据读入控制台应用程序的最快方法是什么

Question

I have a console app written with C++ that needs to accept text input from another process via writeline (followed by a deadline.) I'm assuming that such needs to be done via STDIN, but it also needs to work in the fastest way possible. My console app then needs to reply to the process back.

I haven't done console programming for awhile now, but I remember from C classes at school that there's a lot of C-type functions, like fgets , getline , etc. but what I remember is that they seemed to be quite slow.

So is there any way to do this exchange (again, "quick in and then out") with WinAPIs?

Answer 1

The fastest method in theory will almost certainly be the system level input routines, since both the stdin (in C, but also available in C++) and std::cin build on these. On the other hand, they have generally been optimized for the platform, so unless you can find the optimal configuration yourself (eg things like buffer size), you might not gain much, if anything: calling read (Unix) or ReadFile (Windows) for each character will probably be slower than using something like std::getline .

The other question is what you plan on doing with the data after you've read it. Functions like read or ReadLine give you a buffer ( char[] ) with a certain number of characters; you then have to analyse it, break it into lines, etc. Functions like std::getline give you an std::string with the line in it. If you're a really skilled C++ programmer, you can probably organize things so that the actual data are never moved from the char[] , but this would require re-implementing a lot of things that are already implemented in the standard library. The use of templates in the standard library means that you don't have to implement nearly as much as you would have to otherwise, but you'll still need to create an equivalent to std::string which maintains two iterators ( char const* ) rather than the data itself.

In the end, I'd start by writing the application using std::getline and std::string . Once it's working, I'd see what its actual performance is, and only then, if necessary, consider ways of improving it.