stdio performance in tango, stdlib, and perl

[James Dennett]

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.  However:

GC *is* often used as a crutch by programmers who cannot
or do not want to take time to make a design in which
ownership is clear.

GC is unsuitable for *some* types of mission critical
applications.

These are true.  It's also true that:

Effective use of GC is not restricted to lazy/sloppy/
less capable programmers, and can be used by experts
to produce software that is more reliable in certain
ways.

GC is suitable for some types of mission critical
applications.

GC can affect performance, either positively or
negatively.

GC can affect memory footprint.

Working with GC can cause resource management issues
because many programmers are often tempted to think
less carefully about these issues when there is a
garbage collector to mitigate some of the damage.

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

>>>> I think there is a tendency to assume that APIs and languages which
>>>> have (A) been around a long time and
>>>> (B) been used by millions of people
>>>> will probably be close to optimal.  It just makes sense that that
>>>> would be the case.  Unfortunately, it's all too often just not true.
>>> I just find it strange that C++, a language meant for building speedy
>>> applications, would incorporate iostreams, which is slow, not thread
>>> safe, and not exception safe.
>>
>> 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.

>> 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.

>> Is there something deeper in IOStreams that
>> you consider to be thread-unsafe, or is it just the matter of
>> its global variables?
> 
> All I can do is point to the example above.

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).

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.

-- James