• Welcome to Valhalla Legends Archive.
 

iostream vs stdio

Started by Arta, November 19, 2003, 02:58 PM

Previous topic - Next topic

Which do you prefer?

iostream
6 (46.2%)
stdio
7 (53.8%)

Total Members Voted: 9

Adron

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...

Arta

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.

iago

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 :P
This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Kp

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.
[19:20:23] (BotNet) <[vL]Kp> Any idiot can make a bot with CSB, and many do!

Arta

I agree with kp :)

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

Banana fanna fo fanna

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.

Hostile

Personally I object to STD Input/Output. Its a terrible thing which should be avoided.  :P
- Hostile is sexy.

Adron

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!


Adron

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.  :P

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

Hostile

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.  :P

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).
- Hostile is sexy.

Adron

#25
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...