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