printf or cout ?

[wilk3sy]

My questions always seem to have a similar theme.

Which should I use and why?

printf seems easier to type ???

Thanks

[TarikNeaj]

printf is C.
cout is c++.
pick a language.

I consider cout much easier to use.

[wilk3sy]

whats all this about though...?

cout <<"text" <<endl;

is endl just a replacement for \n ???

[TarikNeaj]

Well. std::endl is not just a replacement for \n. It does what \n does but it does more than that, Im not 100% but I think it also flushed the stream/buffer. These small questions you have are easy to google, so just do that instead.

[Chervil]

endl versus '\n' - often it seems as though these do the same thing. That may be because when sending output to the console with cout, it is automatically flushed.

However, when sending output to a text file, the difference may be clearer - under some circumstances.

Say you have a process which generates a huge amount of output an writes it to a file. I'd suggest just use '\n', it will be more efficient and the end result identical.

Another scenario. Say you have a long-running process which periodically sends output to a log file to report on its progress. If you want to view that log file while the process is running, then it could be better to use 'endl' so that the contents of the physical file is always showing the latest messages.

In summary, use '\n' always - unless you have a specific reason for wanting the buffer to be flushed. (note: I recall that on some operating systems it may be necessary to flush the buffer when outputting to the console).

http://www.cplusplus.com/reference/ostream/endl/

[TheIdeasMan]

is endl just a replacement for \n ???

http://en.cppreference.com/w/cpp/io/manip/endl

std::endl could be inefficient because it flushes the buffer every time. So:

std::cout <<"text\n";

There are pro's and cons for using C++ or C style I/O IMO, one can use C style within C++ (it's a separate implementation to C <cstdio>)

C++ I/O has the advantages that come with streams, while the C style I/O in C++ is sometimes convenient for printing a line which has multiple formats. With std::cout, one has keep swapping formats (by swapping flag variables), but with std::snprintf, one can do it all with one format spec, in 1LOC.

Having said that, apparently using C I/O <stdio.h> in C++ is not type or thread safe.

http://en.cppreference.com/w/cpp/io/c

http://www.drdobbs.com/sutters-mill-the-string-formatters-of-ma/184401458

[dhayden]

It may not be true with modern compilers but when C++ first came out the stream library was horribly slow. That was mostly due to the fact that every output operator was a new function call, and that used other operators which resulted in more function calls. So cout may be slower than printf()

Newer compilers probably inline all those operators. That may be fast, but it also means more bytes in your executable program. So if you have a program that uses lots of stream operations, it's likely to bloat up. On the other hand, if you make a single call to printf(), then you drag in the whole function, which contains all the code to format all the data types it knows about. In other words printf("Hello World\n") contains unused to code to format ints, longs, and doubles, as well as code to align the output at the left or right etc. On the third hand, most operating systems will do dynamic linking on the standard library so that extra printf() code is probably already in memory and being used by lots of other programs: your usage might not add any bytes at all. So in summary: your code size may be a lot bigger OR a lot smaller when using cout vs printf(), depending on the exact circumstances.

It may be quick and easy to write a printf() statement, but you have to get the format specifiers in the format string to agree with the argument list. It's way too easy to mess this up. Also, consider what happens if you change int X to double X after you write your code. Now you have to go through and look for any printf()'s that use X and change the format spec from %d to %g. So cout is typesafe and that is really huge.

As others have pointed out, std::endl flushes the stream. As a minimum this requires a context switch to the operating system. In the worst case, it means physically flushing the data to the hardware (disk, screen, tape, network connection whatever). A disk is a MILLION times slower than memory so there's a good chance that using endl will slow down your program, perhaps slow it down a great deal. You should only use it when you know you need to flush the data.

[TheIdeasMan]

dhayden wrote:

Also, consider what happens if you change int X to double X after you write your code. Now you have to go through and look for any printf()'s that use X and change the format spec from %d to %g.

Hi,

I just tested that, it resulted in a compile error for both situations. You are right though, it would be a pain to go through and change them all. I was under the impression that C style I/O had been re-implemented in C++, I found this in my copy of the draft standard for C++14, it was the same for C++11:


[quote=Cstandard N4140 2014-10-07]17.2
The C standard library
[library.c]
1 The C ++ standard library also makes available the facilities of the C standard library, suitably adjusted to
ensure static type safety.[/quote]

For me, the motivation was 1 line of output, that had 10 different formats. That would take a reasonable amount of code to do with std::cout (even with saving format flags to variables), certainly much more than std::printf. I suppose I could just bite the bullet, it's just more code: so why worry?

I guess the other thing is thread safety, that's looking like a positive for std::cout, is it?

Qt has QString::asprintf() , although there seems to be a documentation bug, look at the last post:

https://forum.qt.io/topic/59868/so-after-qstring-asprintf-was-removed-are-we-supposed-to-implement-printf-patterns-by-ourselves-why/4

[JLBorges]

> For me, the motivation was 1 line of output, that had 10 different formats.

Avoid calling functions with var-args in their own signatures, including legacy functions and standard C library functions such as sprintf. Admittedly, calls to sprintf can often look more compact and easier to read than equivalent calls using stringstream formatting and operator<< — just like it's also admittedly easier to hop into a car without pesky safety belts and bumpers. The risks are just not worth it.

printf-related vulnerabilities continue to be a serious security problem at the time of this writing, and an entire subindustry of tools exists to help find such type errors. Prefer to use type-safe libraries that support variable arguments using other means. For example, the Boost format library uses advanced C++ features to combine safety with speed and convenience.

Alexandrescu and Sutter in 'C++ Coding Standards: 101 Rules, Guidelines, and Best Practices'

[TheIdeasMan]

Right-oh, Will look into that :+)

Cheers

[wilk3sy]

well I'm glad I asked this question, as a lot of useful information has come out of it, not just for me, but others also I believe.

I'm still very new to all this, all this talk of threads etc has me confused. I need to read a lot more!

[keskiverto]

printf formats output to stdout
http://www.cplusplus.com/reference/cstdio/stdout/

cout << formats output to std::cout
http://www.cplusplus.com/reference/iostream/cout/

The stdout and std::cout are corresponding but separate streams as implied by:
http://www.cplusplus.com/reference/ios/ios_base/sync_with_stdio/