C++ advice (scanf/printf)

[brahle]

Always use scanf() and printf(). They are much, much faster than cin and cout. Also use stl algorithms, like sort, reverse and find, especialy if they are member functions of a container class you use.

[Narue]

>Always use scanf() and printf().
Dangerous overgeneralization.

>They are much, much faster than cin and cout.
Uninformed generalization.

>Also use stl algorithms, like sort, reverse and find, especialy
>if they are member functions of a container class you use.
This is actually good advice, though I would have worded it differently: "Prefer the standard library algorithms over writing your own, and prefer member functions over generic alternatives."

Be careful with how you present advice, because if you aren't careful, you'll cause more bad habits than you're trying to prevent.

[brahle]

>Always use scanf() and printf().
Dangerous overgeneralization.

>They are much, much faster than cin and cout.
Uninformed generalization.

>Also use stl algorithms, like sort, reverse and find, especialy
>if they are member functions of a container class you use.
This is actually good advice, though I would have worded it differently: "Prefer the standard library algorithms over writing your own, and prefer member functions over generic alternatives."

Be careful with how you present advice, because if you aren't careful, you'll cause more bad habits than you're trying to prevent.

Have you ever been to competitions? I have, and I know that cin and cout ARE slower. You want proof, here it is. The same program that only writes 100 000 000 bytes of data.

#include <cstdio>
using namespace std;
const int NULA = 0;
int main (void) {
  for( int i = 0; i < 100000000; ++i ) 
    printf( "a" );
	return NULA;
}

#include <iostream>
using namespace std;
const int NULA = 0;
int main (void) {
  for( int i = 0; i < 100000000; ++i ) 
    cout << "a" ;
	return NULA;
}

And do you know why? It is because cin and cout everytime have to get the type of the variable you are sending to them and scanf() and printf() from their prototype know what kind of variables to expect.

[Narue]

>Have you ever been to competitions?
Yes, and I adjust my code accordingly to conform to the rules. However, this is quite irrelevant to your faulty advice because 1) you're just plain wrong, and 2) most of the time, one is not writing code for a competition.

>I know that cin and cout ARE slower.
It depends on what you're testing. Obviously you aren't aware that cin and cout are fully functional objects with a great deal more power and flexibility than scanf and printf. If all you're doing is printing strings then I would expect a naive test to show printf to be faster. However, and this relies heavily on the quality of the implementation, on modern compilers with comparison code written by someone objective and knowledgeable, you won't see much difference in speed.

>You want proof, here it is.
Heh, what are you doing, timing it with a stopwatch? :) Give me your profiler's output, add some timing framework, or don't even waste my time with such a silly test. Oh, and if you're trying to prove something, give me details on your compiler and system.

Let's try this one instead. It's rough, and not entirely portable, but it should give you approximate times for your implementation. Mine shows comparable speeds where the difference varies between printf and cout, and the difference is negligable. That kind of flies in the face of your assertion, doesn't it?

#include <iostream>
#include <cstdio>
#include <ctime>

int main()
{
  std::clock_t start1, start2;
  double diff1, diff2;

  start1 = std::clock();
  for ( int i = 0; i < 100000; i++ )
    std::cout<<"a";
  diff1 = ( std::clock() - start1 ) / (double)CLOCKS_PER_SEC;

  start2 = std::clock();
  for ( int i = 0; i < 100000; i++ )
    printf ( "a" );
  diff2 = ( std::clock() - start2 ) / (double)CLOCKS_PER_SEC;

  std::cout<<"cout:   "<< diff1 <<'\n'
    <<"printf: "<< diff2 <<'\n';
}

>And do you know why?
Yes, I do. That makes one of us. :rolleyes:

>It is because cin and cout everytime have to get the type of the variable you are sending to them
When making a joke, it's customary to add the appropriate smiley. Otherwise I'd be inclined to think that you're spouting nonsense on a subject that you clearly know very little about. My only conclusion is that you're trying to be smart and failing miserably because you seem to be talking to someone who knows way more about C++ than you do.

>and scanf() and printf() from their prototype know what kind of variables to expect.
And in what way do you think that the runtime type selection from a format string with scanf/printf is faster than selecting an overloaded function at compile time?

[brahle]

>Have you ever been to competitions?
Yes, and I adjust my code accordingly to conform to the rules. However, this is quite irrelevant to your faulty advice because 1) you're just plain wrong, and 2) most of the time, one is not writing code for a competition.

>I know that cin and cout ARE slower.
It depends on what you're testing. Obviously you aren't aware that cin and cout are fully functional objects with a great deal more power and flexibility than scanf and printf. If all you're doing is printing strings then I would expect a naive test to show printf to be faster. However, and this relies heavily on the quality of the implementation, on modern compilers with comparison code written by someone objective and knowledgeable, you won't see much difference in speed.

>You want proof, here it is.
Heh, what are you doing, timing it with a stopwatch? :) Give me your profiler's output, add some timing framework, or don't even waste my time with such a silly test. Oh, and if you're trying to prove something, give me details on your compiler and system.

Let's try this one instead. It's rough, and not entirely portable, but it should give you approximate times for your implementation. Mine shows comparable speeds where the difference varies between printf and cout, and the difference is negligable. That kind of flies in the face of your assertion, doesn't it?

#include <iostream>
#include <cstdio>
#include <ctime>

int main()
{
  std::clock_t start1, start2;
  double diff1, diff2;

  start1 = std::clock();
  for ( int i = 0; i < 100000; i++ )
    std::cout<<"a";
  diff1 = ( std::clock() - start1 ) / (double)CLOCKS_PER_SEC;

  start2 = std::clock();
  for ( int i = 0; i < 100000; i++ )
    printf ( "a" );
  diff2 = ( std::clock() - start2 ) / (double)CLOCKS_PER_SEC;

  std::cout<<"cout:   "<< diff1 <<'\n'
    <<"printf: "<< diff2 <<'\n';
}

>And do you know why?
Yes, I do. That makes one of us. :rolleyes:

>It is because cin and cout everytime have to get the type of the variable you are sending to them
When making a joke, it's customary to add the appropriate smiley. Otherwise I'd be inclined to think that you're spouting nonsense on a subject that you clearly know very little about. My only conclusion is that you're trying to be smart and failing miserably because you seem to be talking to someone who knows way more about C++ than you do.

>and scanf() and printf() from their prototype know what kind of variables to expect.
And in what way do you think that the runtime type selection from a format string with scanf/printf is faster than selecting an overloaded function at compile time?

You say you know more about c++ than a man who is included in the development of that language? I somehow don't think so....

[Narue]

>You say you know more about c++ than a man who is included in the development of that language?
Proof by example, my friend. I've proven that I know more about C++ implementations than you do, since the performance aspects aren't tied to the language definition, but rather the specific implementation of compiler and library.

As for being included in the development of the language, I don't care. You could tell me that you're Bjarne Stroustrup, and while I wouldn't believe you just as I don't believe that you've had any significant part in the development of C++, that wouldn't change the fact that you're wrong. And it wouldn't make me respect you any more.

Some people show up and throw around claims that they're teachers, or compiler writers, or that they were on the standards committee, but talk is cheap, and they're usually exposed as nobody's who want to be lavished with admiration without doing any work to earn it.

[brahle]

>You say you know more about c++ than a man who is included in the development of that language?
Proof by example, my friend. I've proven that I know more about C++ implementations than you do, since the performance aspects aren't tied to the language definition, but rather the specific implementation of compiler and library.

As for being included in the development of the language, I don't care. You could tell me that you're Bjarne Stroustrup, and while I wouldn't believe you just as I don't believe that you've had any significant part in the development of C++, that wouldn't change the fact that you're wrong. And it wouldn't make me respect you any more.

Some people show up and throw around claims that they're teachers, or compiler writers, or that they were on the standards committee, but talk is cheap, and they're usually exposed as nobody's who want to be lavished with admiration without doing any work to earn it.

1. And what makes you so clever? Although I am not a sexist, I think that programming isn't 4 woman. Why? I don't remeber any of the great women coders (if you know any, please enlighten me!!!) and I don't remember any woman who won a gold medal on the olympiad.
2. I never mentioned I am in C++ development team!!!!!!!!!! :rolleyes:

[Narue]

>Although I am not a sexist, I think that programming isn't 4 woman.
This would be a fallacy. Circumstantial ad hominem to be precise. Don't change the subject.

>I never mentioned I am in C++ development team!!!!!!!!!!
Oh?

You say you know more about c++ than a man who is included in the development of that language?

This implies strongly that the man you're talking about is you, and "development of that language" is very vague, as I've already mentioned, but it also strongly implies that you've been on a C++ development team, or the standards committee itself. Or were you just lying in the hope that I'd bow down before you and not question your word?

[brahle]

I never mentioned I am in C++ development team!!!!!!!!!!
Oh?

This implies strongly that the man you're talking about is you, and "development of that language" is very vague, as I've already mentioned, but it also strongly implies that you've been on a C++ development team, or the standards committee itself. Or were you just lying in the hope that I'd bow down before you and not question your word?

The man was standing right next to me.

[Narue]

>The man was standing right next to me.
Then tell him he needs to brush up on his C++, or learn to explain things adequately to inadequate people. Because either all of my comments apply to him, or you simply don't understand what he told you well enough to argue your point with someone who knows the subject matter better than you.

[iamthwee]

This thread is getting tedious, brahle you're talking out of your arse, learn some common sense then we might take notice. When is someone going to lock it up and throw it away, where it belongs. :rolleyes:

[Narue]

>When is someone going to lock it up and throw it away, where it belongs.
There's still hope, but I'll lock it when I feel that it needs to be locked. I won't throw it away because there's valuable information contained among the nonsense.

[brahle]

>Have you ever been to competitions?
Yes, and I adjust my code accordingly to conform to the rules. However, this is quite irrelevant to your faulty advice because 1) you're just plain wrong, and 2) most of the time, one is not writing code for a competition.

>I know that cin and cout ARE slower.
It depends on what you're testing. Obviously you aren't aware that cin and cout are fully functional objects with a great deal more power and flexibility than scanf and printf. If all you're doing is printing strings then I would expect a naive test to show printf to be faster. However, and this relies heavily on the quality of the implementation, on modern compilers with comparison code written by someone objective and knowledgeable, you won't see much difference in speed.

>You want proof, here it is.
Heh, what are you doing, timing it with a stopwatch? :) Give me your profiler's output, add some timing framework, or don't even waste my time with such a silly test. Oh, and if you're trying to prove something, give me details on your compiler and system.

Let's try this one instead. It's rough, and not entirely portable, but it should give you approximate times for your implementation. Mine shows comparable speeds where the difference varies between printf and cout, and the difference is negligable. That kind of flies in the face of your assertion, doesn't it?

#include <iostream>
#include <cstdio>
#include <ctime>

int main()
{
  std::clock_t start1, start2;
  double diff1, diff2;

  start1 = std::clock();
  for ( int i = 0; i < 100000; i++ )
    std::cout<<"a";
  diff1 = ( std::clock() - start1 ) / (double)CLOCKS_PER_SEC;

  start2 = std::clock();
  for ( int i = 0; i < 100000; i++ )
    printf ( "a" );
  diff2 = ( std::clock() - start2 ) / (double)CLOCKS_PER_SEC;

  std::cout<<"cout:   "<< diff1 <<'\n'
    <<"printf: "<< diff2 <<'\n';
}

>And do you know why?
Yes, I do. That makes one of us. :rolleyes:

>It is because cin and cout everytime have to get the type of the variable you are sending to them
When making a joke, it's customary to add the appropriate smiley. Otherwise I'd be inclined to think that you're spouting nonsense on a subject that you clearly know very little about. My only conclusion is that you're trying to be smart and failing miserably because you seem to be talking to someone who knows way more about C++ than you do.

>and scanf() and printf() from their prototype know what kind of variables to expect.
And in what way do you think that the runtime type selection from a format string with scanf/printf is faster than selecting an overloaded function at compile time?

Try writing a bigger constant, like 100,000,000. :cool:

[Narue]

>Try writing a bigger constant, like 100,000,000.
Try understanding the phrases "naive comparison" and "negligable difference". The first point concerns the fact that you're not using cout in a comparable way to what printf does, so the test is extremely biased in favor of printf. The second point concerns the fact that if you have to run the loop 100 million times to get any reasonable performance difference, the difference is so small as to be negligable. But I applaud your abundance of free time such that you could run the program with a loop constant of 100,000,000. :rolleyes:

Your initial advice is sound in the proper context, but you're lacking the proper context and trying feverishly to cover your ass after I repeatedly proved your claims incorrect. I highly recommend you quit while you're not too far behind, because it's painfully obvious that you're way out of your league in a technical debate with me on the details of C++.

By the way, I'm still waiting for your response to my other questions. Most notably this one:

And in what way do you think that the runtime type selection from a format string with scanf/printf is faster than selecting an overloaded function at compile time?

And this one:

Oh, and if you're trying to prove something, give me details on your compiler and system.

And out of sheer curiosity, this one:

Heh, what are you doing, timing it with a stopwatch?

[iamthwee]

The thing which makes this thread amusing is that fact that you think using printf instead of cout, may save you time in a coding competition.

What competitions are you entering where such a ridiculous criterion is encouraged.

Don't you realise that these competitions are judged on the strength of the algorithm, and the ingenuity of the coder.
For example, using quicksort over bubble sort. Or applying a dynamic approach as opposed to a brute force one.

Please stop making me cringe with embarassment for you. :eek:

[jwenting]

what makes me wonder is what competition judge would give high marks for someone using C style (IO) routines in a C++ application where a C++ alternative is available.
Programming style is highly important in most competitions, and that's exceedingly poor style.

[Toba]

brahle, just give up. Narue knows her stuff. BTW Narue, did you give up on IRC?

[Rashakil Fol]

Don't give up brahle! You'll just get used to always making sure you're not overgeneralizing, the way we all did when we slammed into Narue...

[jwenting]

I never overgeneralise (how's that for overgeneralisation ;)).

[Rashakil Fol]

Yours doesn't count, because you spelled overgeneralize 'incorrectly' :P

[Toba]

I must have said this a million times - I don't know about you two, but I NEVER generalize or repeat myself.

[brahle]

The thing which makes this thread amusing is that fact that you think using printf instead of cout, may save you time in a coding competition.

What competitions are you entering where such a ridiculous criterion is encouraged.

Don't you realise that these competitions are judged on the strength of the algorithm, and the ingenuity of the coder.
For example, using quicksort over bubble sort. Or applying a dynamic approach as opposed to a brute force one.

Please stop making me cringe with embarassment for you. :eek:

You didn't understand me. I wanted to say that you may save run time when you use printf() and scanf(), not your time. I also think that if you are a good competitor, you must have enough time to double check your algorithm, code it, and still finish an hour early. But sometimes even the best algorithms are ruined when you have large amounts of data to be written and you use cout.

what makes me wonder is what competition judge would give high marks for someone using C style (IO) routines in a C++ application where a C++ alternative is available.
Programming style is highly important in most competitions, and that's exceedingly poor style.

Sorry, but i still haven't bumped into that kind of competition. On most competitions i know (including IOI) the most difficult thing is to stay within the time limit. Nobody asks you for your code, they just want to know if it is correct or not. And on most problems the input is very big (for example, a graph), so you use the faster alterniteve (scanf() rather than cin) to get more time for your algorithm. You may also encounter a problem where you must print out a complete convex hull of a great number of points. And all of them can make the convex hull, so printing them with cout takes more valuable time.

Oh, and if you're trying to prove something, give me details on your compiler and system.

System:
AMD Athlon 2600+
1 GB of RAM
OS: Windows XP Proffesional, SP 2

Compiler:
Compiler is gcc 3.3.6, the compiler that is currently default at Croatian competitions.

[Narue]

System:
AMD Athlon 2600+
1 GB of RAM
OS: Windows XP Proffesional, SP 2

Compiler:
Compiler is gcc 3.3.6, the compiler that is currently default at Croatian competitions.

[node: In hindsight, I should have done this from the start. Had I known you would be so stubborn, I would have.]

Since you're hell bent on avoiding most of my points and assuming that everything is a competition, let's stop playing games and go for *real* speed, eh? I'll abandon any pretense at being diplomatic and say that a good programmer with a good implementation can use cout to blow printf out the water performance-wise for your example and many others.

#include <iostream>
#include <cstdio>
#include <ctime>

int main()
{
  std::clock_t start;
  double diff;

  start = std::clock();
  for ( int i = 0; i < 1000000; i++ )
    printf ( "a" );
  diff = ( std::clock() - start ) / (double)CLOCKS_PER_SEC;

  std::cout<<"printf: "<< diff <<'\n';
}

#include <iostream>
#include <cstdio>
#include <ctime>

int main()
{
  std::clock_t start;
  double diff;
  
  std::cout.sync_with_stdio ( false );

  start = std::clock();
  for ( int i = 0; i < 1000000; i++ )
    std::cout<<"a";
  diff = ( std::clock() - start ) / (double)CLOCKS_PER_SEC;

  std::cout<<"cout:   "<< diff <<'\n';
}

Compile these with full optimization. This is my result (consistent for multiple runs with the expected minor variance):

printf: 22.891
cout:   2.187

The difference is even more apparent with your favorite constant of 100 million, with printf running around 1500 seconds while cout zips along at around 100.

Since all cout is doing is printing a string, you can avoid the overhead of creating a sentry object and shave off more time from cout by going straight to the streambuf:

std::cout.rdbuf()->sputn ( "a", 1 );

That's hardly worth it (a few tenths of a second) until you increase the constant to something really big like 100 million, in which case this change cuts the time by more than half. There's no comparable optimization for printf.

So there you have it, one code change and one compiler settings change and cout makes printf look like the dinosaur that it is. And even then you have options for increasing the speed of cout even more while printf's performance has long since capped. Even better, IOStreams implementations are still immature enough to not take advantage of most of the optimizations available, so you can expect the speed difference to increase to cout's advantage as implementations get better.

Maybe you should rethink your competition strategy.

[brahle]

Sorry, but i don't see your point. Instead of using the cout to view the differnce, i used cerr and i rerouted output to a file. These are the results i got:

printf: 0
cout: 0.10989

When i rased the constant to 10 milion, i gor these results:

printf: 0.10989
cout: 1.31868

This is the code of the tested programs:
printf:

#include <iostream>
#include <cstdio>
#include <ctime>

int main()
{
  std::clock_t start;
  double diff;

  start = std::clock();
  for ( int i = 0; i < 10000000; i++ )
    printf ( "a" );
  diff = ( std::clock() - start ) / (double)CLOCKS_PER_SEC;

  std::cerr<<"printf: "<< diff <<'\n';
}

cout:

#include <iostream>
#include <cstdio>
#include <ctime>

int main()
{
  std::clock_t start;
  double diff;
  
  std::cout.sync_with_stdio ( false );

  start = std::clock();
  for ( int i = 0; i < 10000000; i++ )
    std::cout<<"a";
  diff = ( std::clock() - start ) / (double)CLOCKS_PER_SEC;

  std::cerr<<"cout:   "<< diff <<'\n';
}

[Narue]

> Sorry, but i don't see your point.
I expected nothing less. Very well, I give up. You're beyond helping, but I won't hesitate to keep you from misdirecting others.

[brahle]

Who's misdirecting? I think it is you all the time who is misdirecting. If you need a lot of data to be written, you deffinetly won't use screen, but files.
There isn't everything in the beauty of the code, your program should also be fast enough. There are three things you must do when you write a solution to a problem:
1. write an algotihm by hand on the paper
2. translate it to the programming language you use
3. optimise it as much as you can (erase everything you don't need, like debuging information)

And I know everything isn't in competitions, but at my age, it certainly is. And, btw, have you heard for a coder SnapDragon? He's such a good competitior that he recently stared in the film 'Rent'.

[Narue]

>Who's misdirecting?
I thought I made that abundantly clear. You are, because you lack the experience to understand how things work and believe that your naive tests with older tools define the current state of C++.

>I think it is you all the time who is misdirecting.
Why is that? Because I corrected your misconceptions and you're too stubborn to try and understand?

>If you need a lot of data to be written, you deffinetly won't use screen, but files.
While redirecting the output to a file closes the gap, on a *modern* implementation, cout is still faster. You're relying on a well known flaw of prior versions of your compiler, and that's very misleading to anyone who doesn't realize it.

>3. optimise it as much as you can (erase everything you don't need, like debuging information)
You don't need debugging information? Perhaps for a throwaway contest entry, but in the real world that information is critical for maintenance. You also don't optimize as much as you can; you optimize as much as is necessary. The difference being that the former will turn the code into a maintenance nightmare while the latter will be pleasant to work with and still not be noticeably slower.

Keep in mind that maintenance programmers on a project are the inexperienced ones, so if you optimize as much as you can, you'll make it impossible for them to do their job successfully. Of course, if you never plan to do anything except write code on your own for competitions, you can afford to be as sloppy as you've been so far.

[WolfPack]

And, btw, have you heard for a coder SnapDragon? He's such a good competitior that he recently stared in the film 'Rent'.

This is out of C/C++. But do you mean the Musical called Rent? Starring Mark Cohen?

[iamthwee]

And I know everything isn't in competitions, but at my age, it certainly is. And, btw, have you heard for a coder SnapDragon? He's such a good competitior that he recently stared in the film 'Rent'.

http://www.topcoder.com/tc

Position number two. Yes he is a good coder - you on the other hand I would guess is not. But believe what you wanna believe kiddo, if you think using printf instead of cout will give you an edgein contests then good for you.

I just hope and pray there aren't many people as ignorant as you. :rolleyes:

[Rashakil Fol]

There are three things you must do when you write a solution to a problem:
1. write an algotihm by hand on the paper

BTW, I don't think the English word 'must' means what you think it means.