>>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);