C++ Technical Notes 1 3
C++ Technical Notes 1 3
Macintosh · 1988 · PDF
| Filename | C++_Technical_Notes_1-3_1988.pdf |
|---|---|
| Size | 2.21 MB |
| Year | 1988 |
| Subsection | developer / MPW |
| Downloads | 4 |
Enjoying MacTrove?
Anonymous downloads are free and unlimited.
Create a free account to track favorites,
contribute metadata corrections, and join the
community chat.
Reader
Loading…
OCR / Text contents
(
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…
Showing first 3,000 characters of 64,249 total. Open the full document →
