Re: Order of argument evaluation in C++, et

shepherd@schubert.sbi.com (Marc Shepherd) writes:


      ... C++, of course, was designed to be compatible (insofaras
      possible) with C,...


Yes, this is definitely true. Many legal C programs are legal C++
programs, and even do the same thing.


      ...C, which was designed to be compatible with B,...


Although there are major differences between B and C, this is pretty
much true. B and BCPL have exactly one data type, the word or cell,
which is of fixed size; in particular, this means that character
manipulation was difficult. C, on the other hand, has multiple data
types, of different sizes, and overloads arithmetic operators (that
is, the + operator is used both for fixed and floating-point
addition). B does not have records. B treats pointers and arrays
differently from C. Nonetheless, most existing B code continued to
work in C with minor modifications.


      ...B, which was designed to be compatible with BCPL,...


Compatibility with BCPL was _not_ a goal of B. B's syntax is quite
different (starting with = rather than := for assignment and /*...*/
rather than //... for comments). B's semantics are quite different
from BCPL's (e.g. nested procedures, let, valof). I doubt that _any_
legal BCPL programs are legal B programs with the same meaning.


      ...C, which was designed to be compatible with B, which was
      designed to be compatible with BCPL,...which predates Algol 68.


Now to the crux of the argument. The argument was supposed to show
that a certain semantic property in C++ came from BCPL, which predated
Algol 68, and therefore that the C++ design could not have benefited
from the Algol 68 experience.


There are several problems with this. First of all, there _were_
Algol 68 features that were added to B, notably =+ (now +=).
Secondly, incompatible changes _have_ been made all through the
history of BCPL->B->C->C++. Third, I don't think that this semantic
property (arbitrariness of argument evaluation order) was clearly
specified in B or C, although it was implicitly defined by the only
compilers.


This semantic property most likely came from the proliferation of C
compilers that came with the popularity of Unix, long after Algol 68.
Since there was in fact NO reasonable semantic specification of C at
the time, different compilers had different interpretations. This
pushed the standards committee to accept all the different
interpretations.


Now, there are also substantive arguments on both sides of this
question, but I wanted to stick to the historical issue in this post.
The main connection with comp.compilers is the interesting role that
compilers have played in this process. The B compiler was modified to
become the C compiler, so many of the features of C are "accidents" of
implementation. The proliferation of unrelated compilers in the
absence of a clear language definition led to a later standardization
of a semantics allowing the different variants.


-s


----------------


The information on B, C, and BCPL above is drawn from Dennis Ritchie,
"The Development of the C Language", History of Programming Languages
Conference II, Cambridge, Mass. 1993, in Sigplan Notices (March 1993)
28:3:201.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.