bs@alice.UucP (Bjarne Stroustrup) (10/24/85)
> From: markl@vecpyr.UUCP (Mark Patrick) > Subject: Information on C++/Object Oriented Programming > I would be most grateful if someone could provide me with information > on the availability of documentation/source for C++. Does it support > any form of dynamic typing at runtime? C++ is available educationally & commercially & source & cheap (see mod.newprod for an official announcement). In the US try, AT&T Software Sales and Marketing, PO Box 25000, Greensboro, North Carolina 27420, (800) 828-UNIX or (919) 279-3666. In Europe, try contacting UNIX Europe. They have documentation. You can also try the C++ book: Bjarne Stroustrup: The C++ Programming Language. Addison Wesley, ISBN 0-201-12078-X. Just published. C++ is C with a few problems fixed: - function argument type checking and type conversion - scoped & typed constants (alternative to #define) - inline functions (alternative to #define) - etc. C++ provides a facility for user-defined types: - Simula-like single-inheritance class concept - data hiding - operator overloading - (optional) guaranteed user-defined initialization and cleanup - user-defined type conversion It does indeed support a form of dynamic typing (virtual functions). All the usual claims about data abstraction, object based programming, code re-usability, programmer productivity, maintainability, efficiency, etc. has been made for C++. Some are undoubtedly true. See for yourself. C++ has been in use for about 3 years now. The official announcement refers to a new version where most known problems/bugs are fixed. (No, it is not called ``release F''). It runs on most UNIX boxes (AT&T 3Bs, VAXs, M68Ks, Ahmdals, Pyramids, etc.). You typically need access to a 3B or a VAX to get started. - Bjarne Stroustrup (AT&T Bell Labs)
rmarti@sun.uucp (Bob Marti) (10/25/85)
In message <4478@alice.UUCP>, Bjarne Stroustrup (AT&T Bell Labs) writes: > C++ is C with a few problems fixed: > - function argument type checking and type conversion > - scoped & typed constants (alternative to #define) > - inline functions (alternative to #define) > - etc. This is really interesting! When talking to UNIX/C hackers I always got the impression that the practically non-existent type checking in C was a blessing rather than a problem ... With constants, enumerations (not in K&R!), function argument checking, etc., C's "successor" C++ all of a sudden looks awfully similar to Modula-2, which most UNIX/C hackers tell me is absolutely useless. Never mind that most of these people have never bothered to look into a Modula-2 book, or have even done some Modula-2 programming to the tune of several thousand lines of code. --Bob Marti, {decvax, ucbvax, seismo}!sun!rmarti Disclaimer: I have not looked much into C++, but I'd like to emphasize that from what I have heard so far, it makes a lot of sense to me. I do know "vanilla" C however, and -- having done some serious programming in both Modula-2 and C -- I much prefer the former.
bs@alice.UucP (Bjarne Stroustrup) (10/27/85)
> From: rmarti@sun.uucp (Bob Marti) > Subject: Re: C++ available > > In message <4478@alice.UUCP>, Bjarne Stroustrup (AT&T Bell Labs) writes: > C++ is C with a few problems fixed: > - function argument type checking and type conversion > - scoped & typed constants (alternative to #define) > - inline functions (alternative to #define) > - etc. > > This is really interesting! When talking to UNIX/C hackers I always got the > impression that the practically non-existent type checking in C was a > blessing rather than a problem ... Type checking becomes a disaster if it prevents you from writing resonable programs. For example, if you cannot pass a pointer to a vector of function pointers, or a zero terminated list of pointer arguments you are in trouble. Naturally, C++ has ways for you to specify this, and also ways of declaring old favorites like printf and fprintf. It is important to note that arguments are not only checked, but also coerced if necessary. For example, in a call sqrt(2) the int 2 will be implicitly converted into the required double 2.0 excatly as in an initialization. > With constants, enumerations (not in K&R!), function argument checking, etc., > C's "successor" C++ all of a sudden looks awfully similar to Modula-2, which > most UNIX/C hackers tell me is absolutely useless. Never mind that most of > these people have never bothered to look into a Modula-2 book, or have even > done some Modula-2 programming to the tune of several thousand lines of code. I can assure you that C++ does not look like Modula2. Until you start using the facilities for data abstraction and object oriented programming it looks like C. I personally do not like Modula2, had it appeared as Pascal2 in 1978, it would have been a much more interesting language, and would now be ready for a second major revison. One reason for not reading Modula2 books is that there is none of K&R quality (at least there wasn't one this spring when I last read one). C enumerators are simply integer constants, and does not behave like Pascal enumerated types. In my opinion, it was a mistake to call them enums in the first place. Re. "all of a sudden": The C++ argument typechecking rules were described in S-P&E Jan83, and in greater detail in the special UNIX issue of the BLTJ Oct84. > --Bob Marti, {decvax, ucbvax, seismo}!sun!rmarti > Disclaimer: > I have not looked much into C++, but I'd like to emphasize that from what I > have heard so far, it makes a lot of sense to me. I do know "vanilla" C > however, and -- having done some serious programming in both Modula-2 and C -- > I much prefer the former. You did not comment on the second part of the C++ "feature list": C++ provides a facility for user-defined types: - Simula-like single-inheritance class concept - data hiding - operator overloading - (optional) guaranteed user-defined initialization and cleanup - user-defined type conversion It does indeed support a form of dynamic typing (virtual functions). This is were 95% of the work in designing C++ went and where C++ differ significantly from languages like C and Modula2.
bright@dataioDataio.UUCP (Walter Bright) (10/28/85)
In article <2930@sun.uucp> rmarti@sun.uucp (Bob Marti) writes: >When talking to UNIX/C hackers I always got the >impression that the practically non-existent type checking in C was a >blessing rather than a problem ... > >With constants, enumerations (not in K&R!), function argument checking, etc., >C's "successor" C++ all of a sudden looks awfully similar to Modula-2, which >most UNIX/C hackers tell me is absolutely useless. Never mind that most of >these people have never bothered to look into a Modula-2 book, or have even >done some Modula-2 programming to the tune of several thousand lines of code. I believe most people miss the point about C. It is not the weak type checking that is a feature, it is the ability to escape the typing rules when necessary. Most languages with strong type checking forget to allow for an escape from it. This is why such languages tend to have lousy I/O and storage allocation features. I would like to see a language with strong type checking, yet with an easy and natural escape from it (like how casts are done).
rmarti@sun.uucp (Bob Marti) (10/29/85)
In reponse to message <4487@alice.UUCP> by Bjarne Stroustrup (AT&T Bell Labs):
First of all, let me make absolutely clear that my main intention was to
compare Modula-2 to "vanilla" C and not to C++. Since this may not have
been quite apparent in view of the title "Re: C++ available", I included a
disclaimer to this effect. At this point, I do not know C++ well enough
C++ to be able to critically appraise the language. However, some of your
remarks in your reply to my original posting seem to indicate that your
knowledge of Modula-2 is rather weak as well ...
Now some remarks to the points you raised:
(1) Thank you very much for telling me so much about type checking I did not
know! Seriously, though, I don't see what passing a pointer to a vector
of functions or a zero-terminated list of pointer arguments has to do with
type checking. If you want to say that Modula-2 does not support the
varargs stuff, you are right, it doesn't. You can pass an array or a
pointer to an array of procedure variables, however, and you can also pass
zero-terminated arrays whose elements are of type ADDRESS, and coerce them
into their appropriate types inside that procedure (just like in C). If
C++ does more than that, that is just fine!
(2) Modula-2 does have facilities to define abstract data types, and an
object-oriented programming style is also supported to some degree:
Data abstraction is achieved by the textual separation of type and
procedure declarations from their representations/implementations.
(The representation of a data type can be hidden by declaring an "opaque
type" in a definition module). An object-oriented programming style in
Modula-2 typically involves the use of procedure variables as the fields
of the representation of an opaque type.
(3) I don't know why you think Modula-2 would have been a much more
interesting language if it had appeared in 1978 as Pascal-2 (!), but
I can assure you that Modula-2 *did* appear in late 1978 (see N. Wirth:
"Modula-2." Swiss Federal Institute of Technology Zurich, Instut fuer
Informatik, Report Nr.27, 1978). As far as I recall, even a compiler
generating PDP-11 code was publicly available at that time.
(4) As far as the quality of Modula-2 books, especially Wirth's book, versus
the quality of K&R is concerned, I think this is largely a matter of taste.
But even if you rate K&R considerably higher than Wirth's Modula-2 book,
it still is a very lame excuse for not looking into Modula-2.
(5) Class-concept, inheritance, data hiding, operator overloading, etc. sounds
just fine to me. I will certainly have a thorough look into your book on
C++. It'll probably quite a while until I'll get a chance to use C++,
though. I agree that at least inheritance and operator overloading are
a considerable step beyond the facilities of either C or Modula-2, and
I also realize that the design and implementation of these facilities
are non-trivial, to say the least.
--Bob Marti, {decvax, ucbvax, seismo}!sun!rmartidan@pokey.UUCP (10/30/85)
> > I believe most people miss the point about C. It is not the weak type > checking that is a feature, it is the ability to escape the typing rules > when necessary. Most languages with strong type checking forget to allow > for an escape from it. This is why such languages tend to have lousy I/O > and storage allocation features. > > I would like to see a language with strong type checking, yet with an > easy and natural escape from it (like how casts are done). You're in luck! The language you describe is called "Modula-2"! Not only do you have type conversion functions (i.e., casts), but you have loose types like ADDRESS, BYTE, and WORD. There is even a nifty corner of the language that says ARRAY OF WORD (and of BYTE, actually), is procedure parameter compatible with _any_ type (this means that you can write a generalized multi-byte file I/O routine, and use _anything_ as the object to be I/Oed. Once in the routine, you can ask for HIGH(x) to find out how big it is. Look, no pointers!). By the way, if the (admittedly crummy) Wirth text is getting in the way of you learning the language, try the new "Programming in Modula-2" by Ogilvie, published by McGraw-Hill. It's super!
rmarti@sun.uucp (Bob Marti) (10/30/85)
>> When talking to UNIX/C hackers I always got the >> impression that the practically non-existent type checking in C was a >> blessing rather than a problem ... >> >> With constants, enumerations (not in K&R!), function argument checking, etc., >> C's "successor" C++ all of a sudden looks awfully similar to Modula-2, which >> most UNIX/C hackers tell me is absolutely useless. Never mind that most of >> these people have never bothered to look into a Modula-2 book, or have even >> done some Modula-2 programming to the tune of several thousand lines of code. > I believe most people miss the point about C. It is not the weak type > checking that is a feature, it is the ability to escape the typing rules > when necessary. Most languages with strong type checking forget to allow > for an escape from it. This is why such languages tend to have lousy I/O > and storage allocation features. > > I would like to see a language with strong type checking, yet with an > easy and natural escape from it (like how casts are done). You obviously have not looked into Modula-2 either, or you would know that it has type transfer functions which are almost exactly like type casts in C. Only the syntax is slightly different: TypeIdentifier "(" Expression ")" instead of "(" TypeSpecifier ")" Expression