when you use any of the c++ i/o you're including statically alot of code, so your exe is HUEG
Name:
Anonymous2007-11-22 14:46
SEPPLES ITT
Name:
Anonymous2007-11-22 14:50
I was just thinking about iostreams yesterday. What the fuck? Why did they ever think cout << "Yo" << " I'm " << 6 " fags!" << endl;
was a good idea? Not only does it look like bit shifts, it's longer and harder to read than the alternative would have been.
Name:
Anonymous2007-11-22 15:41
>>8
They probably did it to show off how C++ could overload operators and use objects. OMG NEW FEATURE LETS USE IT!!!111
>>6
You can link dynamically too, but it's still a very roundabout way of doing it (IIRC cout eventually calls through printf or something)
>>15
i'd imagine stdio to be, but not by a whole lot
Name:
Anonymous2007-11-22 20:43
>>16
I actually haven't measured it, but I imagine cout is faster, or rather, has the potential to be faster. because printf interprets the format string, the cout stuff is determined at compile time.
Ok, yes, it's not a huge overhead. I'm a moron, forget it.
Name:
Anonymous2007-11-22 20:59
>>15
gcc win32 codeblocks full opt.
a: 0.015s av. over 10 runs
b: 0.032s av. over 10 runs
I would only use c++ i/o when stdio isnt adaquete, such as displaying int64s, cout is overloaded to work with 64 and 128 bit (i think) binaries
Name:
Anonymous2007-11-22 23:33
>>22
Or you can lrn codez and actually program properly rather than using moronic fucking languagehacks.
Name:
Anonymous2007-11-23 3:07
cout doesn't have to run a fucking interpreter with % tags and parameters scattered in different places.
Name:
Anonymous2007-11-23 4:19
>>24
You make it sound like parsing a string and interpolating values when you encounter a sigil is somehow computationally intensive.
Name:
Anonymous2007-11-23 5:52
>>24
You make it sound like writing friend functions of operator<<(ostream &, T &) is somehow the lesser evil to an extremely minor performance difference.
(I mean, it didn't matter even on a kilohetrz-clocked PDP-8!)
Name:
Anonymous2007-11-23 5:59
OH FOR FUCKS SAKE ?? 26 POSTS ON THIS THREAD GOOOD DAMN IT SHUT UP EVERYONE IM TRYING TO SLEEP
>>1
Stroustrup is the biggest troll ever, who the fuck would really think about overloading bitwise operators and saying that it's better learning C++ without any knowledge of C. Listen to people like Paul Graham and The Sussman they know what they are talking about.
>>22
printf() in 64-bit and 128-bit environments would by necessity support outputting those sizes.
>>24
There's fwrite(), puts() and other output functions that don't do formatting if you don't need it. But most of the time you do need the formatting, and that's when something like "%08X-%08X-%c|%d/%d%%" in a single printf() is better than a whole bunch of setxxx() calls.
No, this was anticipated. It was found that deterring ill behaved new users was of greater importance than being `trolled' by an established member of this community.
>>35-40 HAHAHAHA
YOU THINK YOURE THOUGH UH ?
I HAVE ONE WORD FOR YOU
THE FORCED INDENTATION OF THE CODE
GET IT ?
I DONT THINK SO
YOU DONT KNOW ABOUT MY OTHER CAR I GUESS ?
ITS A CDR
AND IS PRONOUNCED ``CUDDER'' OK YOU FUQIN ANGERED AN EXPERT PROGRAMMER
THIS IS/prog/
YOU ARE ALLOWED TO POST HERE ONLY IF YOU HAVE ACHIEVED SATORI
PROGRAMMING IS ALL ABOUT ``ABSTRACT BULLSHITE'' THAT YOU WILL NEVER COMPREHEND
I HAVE READ SICP
IF ITS NOT DONE YOU HAVE TO
TOO BAD RUBY ON RAILS IS SLOW AS FUCK
BBCODE AND((SCHEME)) ARE THE ULTIMATE LANGUAGES
ALSO
WELCOME TO/prog/
EVERY THREAD WILL BE REPLIED TO
NO EXCEPTION
>>17
Not to mention printf() is vulnerable to buffer overflows OH SNAP
Name:
Anonymous2007-11-24 22:03
>>46
Uhh... no it isn't, since it's writing directly to stdout and not touching the stack. sprintf, strcpy, strcat, gets, etc... are vuln to buffer overflow.
>>1
Once you start working on important things the usefulness of iostream really starts to decline, because the important things have a GUI, or you're working in places far awar from where the output and input are generated. About the only thing for iostream to do in programs like these is update error logs. Especially if you consider what C++ spends most of its time doing in the real world.
If you're just doing your homework or something then there is no need to listen to anyone's performance claims, but it probably doesn't matter anyway.
>>31
not if you have a 32 bit environment and needs to do 64 bit arithmetic somehow, then cout could already display it, and I dont think the commitee added a int64 modifier to printf, %ld is long %lld is long long?
Name:
Anonymous2007-11-27 16:39
>>62
They're the optimization switches. They change how gcc translates it to ASM.
Name:
Anonymous2007-11-27 19:50
>>64
Look into <stdint.h> and <inttypes.h>
They've added stuff like uint64_t for example, and to print it using printf() you write
uint64_t n = UINT64_MAX;
printf("%"PRIu64"\n", n);