C++ Technical Notes 1 3

( C++ Technical Notes-Number 1 H. Kanner Development Systems Group 29 February 1988 This is the first of a series of technical notes on the C++ language. Because there is as yet only one book on the language, TM C++ Programming Language by Bjarne Stroustrup, and many sections of the book have been written in a difficult to follow style, I felt that it might be of use to write some notes on various aspects of the language with which I initially had difficulty. By the way, the cited book will be refeITed to here and henceforth as The Book. It has often been said that the ultimate definition of a programming language is the official compiler. That is, the semantics of a piece of source code is really understood by inspecting the output of the compiler. In the case of the AT&T C++ compiler, this task is made easier by the fact that this output is C code. I cannot too strongly recommend to readers that they try to clear up linguistic obscurities by consttucting the simplest possible test cases, running them through cfront, and looking at the output. One warning: do not try this with an inliM function. This fust note deals with references. I anticipate a minimum of two more notes, to be published when I feel I understand the subjects sufticiendy. They will respectively cover constructors and destn1etors, with emphasis on their storage management aspects, and overloaded opezators, with emphasis on the distinction between defining them as TMmbers or friends. I had a little difficulty understanding why references had been introduced into C++. They are an exception to the symmetry of the terrible C notation for declarations, in which one can at least say that operators such as •, Q,_311d Dhave the same meaning when used in a declaration as when used in an expression. That is, char *s; char* t; char c • *t; all use the * to denote dereferencing a pointer. The first of the above three lines should literally be read: "If you were to dereferences, you would get a char." It is ttue that the compiler does not care where the white space is, and Bjame prefers the style of the second line, which he likes to state as "t is a pointer to char," as if char* represented the type "pointer to char." This is very informal. In fact he cautions that if you wril8 ._ chait"* s,t,u; only the first~ dlele will be a poinrer to char; the second two will be declared as char. A reference uses the & symbol. But int& means reference to int, &x means address of x, and neither of int& x; int &x; can be interpreted as "If you were to take the address of x,. you would get an int." ,./ 2 I now whet the reader's interest by making a promise. By the end of this note, I will have illustrated that references make it possible for the following to be perfectly legal C++: int i; f(i) - 10; I introduce references by exploring to the point of tediousness what we really mean when we say int i. The symbol i is regarded as a synonym for the address, to be determined at some fuwre time, of a…