--Rationale-- (to be expanded in the actual application)
* Parsing of C++ is slow
* On large projects, compile times often dominate the compile/edit/debug cycle
* Changes in source are often small and isolated
* Preprocessed compilation units are often huge - esp. compared to the
size of changes.
Wow, lots of comments there, Mike ;-)
We saw a 41% speed-up for SimpleText, a 110x peak speedup for
and (cstdlib). A C++ Carbon hello world was 91x faster,
peak. C hello world was the same speed. Peak speedups for C 2x,
for C++ 142x.
Cool! After some measurements (-ftime-report, tee, gre
In this case, you don't have to look far to see that you can't use the
return value of printf.
According to my manpage, printf returns 0 on success, 1 on failure. No
mention of the number of characters written. This is different with
sprintf/snprintf (see e.g
http://www.opengroup.org/onlinepubs/0
m is very close to 100% ;-)
// Simon
On 6/6/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 06 June 2007 12:04, Simon Brenner wrote:
> According to my manpage, printf returns 0 on success, 1 on failure. No
> mention of the number of characters written.
Well, maybe you should ...
>
Simon, you need to type:
man 3 printf
to read about printf() the C function.
Argh! Indeed I was reading the wrong manpage. That probably means
almost everything I've concluded and said was wrong :/ Apparently,
throwing your two cents in can reduce the total value of a discussion.
According to
