At 09:57 AM 7/15/2004, Bill Long wrote:


>Drew correctly points out that C has been very successful, especially as
>a language for writing operating systems.  This should not be a
>surprise. C was designed to be an OS implementation language.  In OS
>code you need to directly manhandle memory addresses.  C is designed for
>this task.  However, it is not necessarily the case that a good OS
>implementation language is also ideal for writing scientific code that
>runs efficiently, which, if I recall, was the original inquiry.  Indeed,
>C's pointer centric design, which is so well suited for system software,
>is also the root of its optimization problems.  Fortran, on the other
>hand, was designed for scientific programming, and for enabling the
>generation of efficient code.  It makes sense to use languages for their
>intended purposes.

I spent a good part of the day in a discussion whether it is even legal, by
the definition of C++, to assume any possibility of parallel execution of
C++ STL iterators.  I don't see much C which doesn't borrow a bit from
C++.  Nor do I see the posited vast body of competent scientific
programmers who are well trained in pure C and won't be tempted to mix in
C++, but would have more difficulty becoming competent in Fortran.
The problem of the day has to do with the vast majority of C++ iterator
templates, which are written in the style
while(operand pointer not equal to pointer one beyond last operand){....}
and the ensuing debate about whether the loop count can be determined in
time to allow any parallelism.
The case where the operand pointer is set initially beyond the stopping
value is not explicitly disallowed, even though it has no portable
interpretation.  The "not equal to guard value" is supposed to carry useful
additional generality beyond the "less than guard value" alternative which
would favor optimization.
The Fortran committee saw fit 30 years ago to come down in favor of syntax
which requires the loop count to be calculated prior to executing it, while
other languages make a virtue of avoiding syntax which allows that.


Tim Prince