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 ####, 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