I just ran Narue's test on my XP, 2.41 GHz AMD Processor, 1 Gig RAM and pretty fast video card.
compiled with Visual C++ 2005 Express editiion in release mode. One problem with such as test is variance in speed of hardware -- you will get much different results with different video cards and processor speed. That alone will invalidate any such speed difference tests.

Using Microsoft compilers, I am not at all convinced that std::cout is faster than printf(). I have made similar tests in the past on other computers with M$ os and have never seen one where cout is faster than printf(). And I would be supprised if *nix computers was any different.

>That alone will invalidate any such speed difference tests.
Such is the way with any benchmark, but since brahle felt the need to post a speed test that proved his point (though I still can't imagine how, since he didn't have any timing framework and didn't post any profiler output), I did the same.

>I have made similar tests in the past on other computers
>with M$ os and have never seen one where cout is faster than printf().
Yes, in the past. And you don't seem to take note that quality of implementation is a huge factor. Many implementations of cout would just be a wrapper around some variant of printf, which, with the added overhead of a sentry object and various stream tests, would cause cout to be significantly slower than printf. That's where the misconception that printf is and always will be faster than cout came from.

However, on modern implementations, library writers are finally starting to realize that they can take advantage of several optimizations that can make cout *faster* than printf. We're starting to see those optimizations, and with a good implementation, such as STLPort (IIRC), cout beats printf almost every time, and that gap will only increase as implementors get better at taking advantage of C++.

>And I would be supprised if *nix computers was any different.
Then you've obviously already made up your mind, much like brahle.

Ah well, at least I tried. :rolleyes:

Although I think the real point here is that it doesn't really matter whether cout is slower than printf. I can think of few situations outside of a programming-for-speed competition where the relatively small speed difference between printf/scanf and iostreams is of greater consequence than the ugly C-style code which results in the use of printf. Especially when considering that the 'advice' has been directed to a forum populated with many learner programmers, students, and C++ beginners.

I will agree that when writing c++ program use c++ stream classes and not resort to C. There are many benefits to using streams than just a few micro-nanoseconds speed. I wouldn't have even posted in this thread had I not read Narue's test and tried it on my own computer. I haven't used STLPort or boost libraries, so no comment there.

>I will agree that when writing c++ program use c++ stream classes and not resort to C.

But we all knew that. It's just that Brahle didn't.

And his justification for using printf was rather poor. Coding competitions, he said. Pfft, where apparently the code is judged on it's time from execution to end and nothing else.

Not on its content cos that would be just silly? And hell Brahle even goes on to say that in these coding competitions he has to handle data in the order of tens of millions. And that's of course where using printf instead of cout makes a difference? :rolleyes:

Nonsense, nonsense, nonsense.

I believe Brahle lives in a world of make belief, where all kinds of non-existent characters dwell, like elves, pixies and eskimos.
:lol:

Narue, I am amazed at the depth and breadth of your C/C++ knowledge. You truly make this board worth reading.

On a different note, I think I need to break the rust off my C++ skills. Your code makes me realize that C is not the be-all end-all of programming languages.

>C is not the be-all end-all of programming languages.
Blasphemy!

That's what my boss says

Still, spending the last five years writing low-level C code has given me a strong affinity for the language. K&R were right - C is a small language, and is best served by a small book.

>>C is a small language, and is best served by a small book

but it has an abnormally huge price! Just because K&R was written by the language's authors doesn't mean it is any better than books twice as big and half the price. That K&R book with white cover is grossly overrated.

>That K&R book with white cover is grossly overrated.
I'd like to disagree. I'm on my second personal copy because the first one fell apart due to excessive thumbing through the pages, and the (rather good) binding is starting to come apart on my second copy as well. I have a large number of books on C, which I've read cover to cover, and I can safely say (barring the C standard itself) that I value K&R the most.