overloading operators for I/O

James Dennett jdennett at acm.org
Sat Feb 17 18:03:25 PST 2007


Andrei Alexandrescu (See Website For Email) wrote:
> Walter Bright wrote:
>> Michiel wrote:
>>> Bill Baxter wrote:
>>>
>>>>> But it has the added advantage that there is no need for run-time
>>>>> parsing of that string. C++ parses all << stuff at compile time.
>>>>>
>>>> I wonder how much difference that makes given that most IO tends to be
>>>> slow anyway.   On a 1 GHz proc, with a disk that has 10msec seek time
>>>> that means a hit to the disk can cost you ten million cycles, right?
>>>>
>>>> Spending a few cycles to parse a format string at runtime isn't
>>>> going to
>>>> kill you.
>>>
>>> Well, you're right of course. But strictly speaking it's still an
>>> advantage. ;)
>>
>> C++ iostreams has the further "advantage" of being neither
>> exception-safe nor thread-safe (since it manipulates global state in
>> order to do formatting). 

Hmmmmn, the only global state is the standard stream objects,
and you don't have to use those.  The use of globals is
certainly a nightmare for thread-safety (though exception
safety is less of an issue), but it's limited to this one
set of global variables.

>> This is only excusable because iostreams was
>> added to C++ years before exception handling was and before anyone
>> knew anything about threaded programming.
> 
> It's a myth that iostreams benefit much the speed advantage of not
> needing to do type retrieval at runtime. 

I think current implementations aren't very good.  And given
how long we've had since IOStreams was first used, that's not
an optimistic picture.

> They are marred by a convoluted
> design and the need to synchronize with C's stdio library.

The latter is turned off with a function call, which does
make a significant difference.  The convoluted design is
just unfortunate.  IOStreams isn't useful for much serious
work.  Not for notational reasons though; the design is
just lousy.

-- James



More information about the Digitalmars-d mailing list