| | |
C++ advice (scanf/printf)
![]() |
>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.
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.
I'm here to prove you wrong.
•
•
•
•
Originally Posted by 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.
C++ Syntax (Toggle Plain Text)
#include <cstdio> using namespace std; const int NULA = 0; int main (void) { for( int i = 0; i < 100000000; ++i ) printf( "a" ); return NULA; }
C++ Syntax (Toggle Plain Text)
#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.
Revenage is a dish best served cold.
50|2|2Y 4 |34|) 3|\|6|_|5|-| >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?
>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?
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?
C++ Syntax (Toggle Plain Text)
#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'; }
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?
I'm here to prove you wrong.
•
•
•
•
Originally Posted by 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?
>And do you know why?C++ Syntax (Toggle Plain Text)
#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'; }
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?
Revenage is a dish best served cold.
50|2|2Y 4 |34|) 3|\|6|_|5|-| >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.
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.
I'm here to prove you wrong.
•
•
•
•
Originally Posted by 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.
2. I never mentioned I am in C++ development team!!!!!!!!!! :rolleyes:
Revenage is a dish best served cold.
50|2|2Y 4 |34|) 3|\|6|_|5|-| >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?
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?
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?
•
•
•
•
Originally Posted by brahle
You say you know more about c++ than a man who is included in the development of that language?
I'm here to prove you wrong.
•
•
•
•
Originally Posted by Narue
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?
Revenage is a dish best served cold.
50|2|2Y 4 |34|) 3|\|6|_|5|-| >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.
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.
I'm here to prove you wrong.
![]() |
Other Threads in the C++ Forum
- Previous Thread: Simulation of Main memory compression
- Next Thread: Need help with CPU scheduling algorithms
| Thread Tools | Search this Thread |
ace_thread api array based binary bitmap borland c++ c/c++ calling char class classes code coding compile console conversion count delete delete-line deploy desktop developer directshow dll download dynamic dynamiccharacterarray email embedded encryption error file forms fstream function functions game givemetehcodez graph gui homeworkhelp homeworkhelper iamthwee ifstream information input int integer java lib linkedlist linker loop looping loops map math mathhomeworkhelp matrix memory multiple news node number numbertoword output parameter pointer problem program programming project python random read recursion reference reverse richedit rpg string strings temperature template test text text-file tree url variable vector video win32 windows winsock word wordfrequency wxwidgets





