Valhalla Legends Archive

If those large calls go to short functions and that small call goes to a long function where the entire code isn't executed, the small call seems mostly better to me. It depends on how often you'll be calling it though...

I think iago makes a good point. On the face of it, it looks as though stdio is clearly superior, but i very much doubt it's as clear-cut as that. I was referring more to the internals of printf and cout.

Write a program that counts from 0 to INT_MAX or 1000000 or something, and have it print out each number (doesn't matter which way).  Time it.  When it finishes, do it again without printing.  Notice how it takes like 1% of the time (I'm guessing, never actually tried)?   I/O is extremely slow, so I don't see why it matters whether or not the code you're using is terribly efficient for calling the I/O in the first place!

Even stupider is worrying about how well cin works, but I don't need to explain that one

Quote from: iago on November 20, 2003, 10:06 PM
I/O is extremely slow, so I don't see why it matters whether or not the code you're using is terribly efficient for calling the I/O in the first place!

Sure, it's slow.  However, as I recall, it's faster to write output to something other than the terminal due to better buffering.  Even setting that aside, it seems like a bad idea to justify non-optimization of code on the grounds that it will still be slow.  Java programs run slowly because they're (usually) bytecode, and that's all the more reason that they need to be optimized, so that the slowness of the VM is the only thing pestering the user.

I agree with kp

I might run that test when I'm bored one day though, it could be interesting.

On a performance-unrelated note, I think that C++ has too much operator overloading nonsense. I think operator overloading is good for stuff like ==, >, < etc, but it can get confusing when an operator does something it doesn't usually do.

For example, when I first learned C++, it took me forever to figure out that I wasn't bitshifting a string to write it to the console.

Personally I object to STD Input/Output. Its a terrible thing which should be avoided.  

Quote from: iago on November 20, 2003, 10:06 PM
I/O is extremely slow, so I don't see why it matters whether or not the code you're using is terribly efficient for calling the I/O in the first place!

This means that the speed of the code doesn't matter. The size still does though if you have a lot of printing in your application. Smaller executable!

Quote from: Hostile on November 21, 2003, 07:21 PM
Personally I object to STD Input/Output. Its a terrible thing which should be avoided.  

Standard input/output make it easy for users to do big things by combining several small tools through piping etc.

Quote from: Adron on November 21, 2003, 08:54 PM

Quote from: Hostile on November 21, 2003, 07:21 PM
Personally I object to STD Input/Output. Its a terrible thing which should be avoided.  

Standard input/output make it easy for users to do big things by combining several small tools through piping etc.

hmm, I had a slightly hidden joke in there, perhaps misplaced. I was refering to STDs (Sexually Transmitted Diseases).

Quote from: Hostile on November 22, 2003, 11:16 PM
hmm, I had a slightly hidden joke in there, perhaps misplaced. I was refering to STDs (Sexually Transmitted Diseases).

Oh, and after all the STD arguing I've done, I missed that. What a shame. I was thinking STD_INPUT_HANDLE...