stdio performance in tango, stdlib, and perl

[Walter Bright]

James Dennett wrote:
> Walter Bright wrote:
>> James Dennett wrote:
>>> Walter Bright wrote:
>>>> But still, there are one or two that repeat the conventional (and wrong)
>>>> wisdom about garbage collection. Such conventional wisdom is much more
>>>> common among the general population of C++ programmers.
>>> Which "wrong" assertions are those?
>> gc is a crutch for lazy/sloppy/less capable programmers, gc isn't for
>> mission critical industrial apps, gc is for academic unusable languages,
>> etc.
> 
> I've seen only a minority of those claims made as part
> of the C++ committee discussions of GC.

I think we're in agreement, as I said "one or two", and that such claims 
are not made in general by the top tier of C++ programmers.

> Almost all discussions of the pros and cons of GC are
> simplistic and unbalanced.

It's not humanly possible to mention every pro and every con in every 
discussion. Nobody is making a claim of absolutes, either. For every 
example, sure, you can find a counter-example.

That doesn't mean one cannot have a meaningful discussion about the pros 
  and cons of adding gc, and it doesn't mean we can't dismiss certain 
arguments against gc, like it being a crutch for lazy programmers.

>>> I'm intrigued by your claim that IOStreams is not thread-safe;
>>> the IOStreams framework is thread-safe in the same way that
>>> the STL is thread-safe.  The one minor difference is that
>>> IOStreams exposes some global variables, which is unfortunate
>>> as they can easily be used in inappropriate ways in a
>>> multi-threaded environment.
>> Note the reliance here on global state that is neither thread nor
>> exception safe:
>>
>> std::ios_base::fmtflags flags_save = std::cout.flags();
>> std::cout << 123 << '|' << std::left << std::setw(8) << 456 << "|" <<
>> 789 << std::endl;
>> std::cout.flags(flags_save);
> 
> True, exception-safety is an issue.  There is not
> a threading issue in the code above *except* that
> it uses a global variable without synchronization;
> you explicitly coded reliance on global state, by
> using a global variable.  Unfortunately that's
> easily done with the IOStreams interface.

That's the design of iostreams - reliance on global state with no 
multithreading protection. Using std::left is not a mistake on my part, 
it is a feature of iostreams. Also,
	cout << a << b;
has multithreading problems as well, as if two threads are writing to 
stdout, the output of a and b can be interleaved with the other thread's 
output. Note that:
	writefln(a, b);
is both exception safe and thread safe - there will be no interleaving 
of output.

>>> Then again, that is unsurprising
>>> as C++ does not yet officially incorporate support for
>>> multi-threading.
>> That's not an excuse, as 1) multithreading was common long before C++98
>> was written and 2) multithreading and exception safety was thought about
>> and accounted for in much of the rest of the library design, despite
>> threading not being official.
> 
> I wasn't aiming to make an excuse.  I was merely noting
> that it's not surprising.  IOStreams was old before the
> 1998 standard was published; this was a case of the
> standards committee doing what it was supposed to do,
> i.e., standardizing existing practice.

Iostreams was substantially redesigned for C++98. Iostreams has 
undergone two major, incompatible overhauls since it originally debuted. 
You can see the old ones in DMC++'s <iostream.h> and <oldstr/stream.h>.

> I see exception-safety issues, but no threading issue
> apart from *if* your code fails to synchronize access
> to a global variable.  So far as I can tell, there are
> not thread-safety issues unless multiple threads share
> a stream without synchronization (which is just as
> much of a defect as if they shared a container without
> synchronization).

You can use C's stdio and D's stdio (and even mix them) without 
exception safety problems or need for the user to supply any 
synchronization.

> Automatic synchronization tends to be at the wrong
> level, just as in the case of containers etc.  Most
> often in robust code it's redundant to make a stream
> synchronize itself.
> 
> Anyway, I was just hoping to find out something I
> didn't already know.  One thing we do know is that
> IOStreams is not the gold standard for I/O interfaces,
> though it does have strengths in extensibility and
> type-safety compared to the alternatives in most
> C-like languages.

I agree it has strengths in extensibility and type-safety. But I set 
that against its poor performance, exception unsafety, and threading 
problems, and conclude it is not a design that should be emulated.