JC> Try a bit of testing:
JC> Now, note that this is writing to the NUL device, so no output is ever
JC> actually generated at all.  What we're doing here is simply reducing the
JC> overhead in having to call the OS evertime we want to write a character.
JC> After we do that, the OS simply discards the character.
    Using win95 win32 console target, output to an actual file was faster.
    For the non-buffered version it was over 4x faster. 
    Using a DOS target, the file version was undected and the null version
    took a considerable amount of time.
    the win16 target was unrealiable because it produced output to the 
reen.
    
    The non-buffered version for all was considerable slower that the 
uffered
    , this was shocking to me.
JC> On my system, the version with buffering turned on is roughly 20 times
JC> as fast as the version with it turned off.
    On my system, the buffered version was 1/70th the time taken for the
    other.
JC> their C counterparts.  They may be more typesafe, but in many cases
JC> taking a 2 or 3:1 speed hit simply isn't acceptable.
    Using class ofstream compared to the C counterpart was 1.44 to 1.99
    seconds. A little bit slower but not quite so noticable when we
    are talking about a fraction of a second difference. This was quite
    a trivial example and I don't think it was a good example for me
    to compare putc with "<<" speeds for output. I don't know enough C
    to produce a good example of speed differences in the two.
--- GEcho 1.00
---------------