bs@alice.UUCP (Bjarne Stroustrup) (06/14/89)
Producing a meaningful comparison of two (or more) languages is a difficult task worthy of many months work (definitely involving actual programming in both languages and consultation with diverse groups of people having completed projects in both languages). When done well, such studies are good candidates for a major papers and significant contributions to the culture surrounding programming. When done badly such studies can be a sham and a travesty. It is definitely not a job for novices and definitely not a job for people deeply involved in one language (and not the others) or with other major demands on their time. So this note and the ones following discuss C++'s design and some C++ features in a way that I imagine might be helpful to someone trying to compare C++ to other languages/systems or simply to get an idea of what C++ is about and where to find more information. For a more solid and considered treatment of C++ see the literature. In particular, see my paper `What is Object-Oriented Programming?' that can be found in the May'88 issue of IEEE Software magazine. This paper essentially presents the view of what C++ is supposed to grow into. It was first presented (in essentially its current form) to the Simula Users' Group in Stockholm, August 1986. A more detailed look at some of the directions in which C++ is growing can be found in `Possible Directions for C++' in the Proceedings of the first USENIX C++ conference. For a much more diverse view of C++ see the two proceedings from the two USENIX C++ conferences. These papers have the advantage of providing insights into C++ and its use from many different people - only a minority of whom are affiliated with any of the C++ purveyors. Other good sources of information about C++ are `The C++ Report' (a newsletter) and Andrew Koenig's C++ column in the Journal of Object Oriented Programming. Should any of this increase your interest to the point where reading a textbook seems worth the effort here is a selection (in chronological order more or less): Stroustrup, Bjarne: "The C++ Programming Language," Addison-Wesley, 1986. Wiener, Richard S., Pinson, Lewis J.: "An Introduction to Object-Oriented Programming and C++," Addison-Wesley, 1988. Berry, John: "The Waite Group's C++ Programming," Howard W. Sams & Company, 1988. Pohl, Ira: "C++ for C programmers," Benjamin Cummings. 1989. Dewhurst, Steve and Stark, Kathy: "Programming in C++," Prentice Hall, ISBN 0-13-723156-3. Lippman, Stan: "A C++ Primer," Addison Wesley ISBN: 0-201-16487-6 Hansen, Tony: "The C++ Answer Book," Addison Wesley ISBN: 0-201-11497-6 (announced) Gorlen, Keith: "A Guide to Object-Oriented Programming in C++," John Wiley & Sons (announced) Eckel, Bruce: "Using C++," Osborne/McGraw-Hill (July, 1989) Someone from Oregon Software occationally posts a rather complete C++ bibliography to comp.lang.c++.
bs@alice.UUCP (Bjarne Stroustrup) (06/14/89)
Given the widespread rumers (sic) to the contrary, it might be worth pointing out that C++ was designed with a careful consideration of principles such as type safety, consistency, encapsulation, orthogonality, minimalism, and completeness. These ideals are, in particular, the reason why C++ could not simple preprocessor adding a few features to an otherwise untouched C. The need for a coherent and unified type system precludes that. The stated aim for C++ (see the first paragraph of my book) is to ``make programming more enjoyable for serious programmers.'' It does so by directly attacking the problems that can make life miserable for a programmer or a group of programmers: by providing support for good design, by allowing ideas to be expressed directly in the language, by providing checking of programs, by allowing the programmer to provide sufficient structure in a program to make tools effective, by making good design and programming techniques affordable, and by making good design and programming techniques available on essentially all kinds of systems. This may not have been stated clearly enough in the past. At least I have seen postings presenting the view that compatibility was C++'s major or even C++'s only goal. It wasn't and isn't. Compatibility provides a way of co-existing with more traditional systems, a path for people who cannot make immediate radical breaks with the past to follow, a way of preserving skills, a way of re-using tools and libraries, and a way of guaranteeing completeness of a new language.
bs@alice.UUCP (Bjarne Stroustrup) (06/14/89)
C++ is designed to cater for a wider range of programming styles, a wider range of applications, running on a wider range of systems, and under a stricter set of efficiency requirements than is most other higher-level languages. The complexity of C++ reflects this range of uses and requirements. Given this, estimates of C++'s complexity is often greatly inflated. Any language/system that tries to cover the ground C++ covers will approximate C++ in complexity. Any that doesn't will leave you to write many programs and large parts of systems in other languages. For example, if there is a problem with efficiency (run-time or space) or if the language require a certain class of machine you will end up writing in C, assembler, Fortran, etc. It seems trivial to improve C++ by reducing its size by 20%, but I have never met two people who could agree on exactly which 20%. It would be trivial to design a syntax for C++ that was noticeably easier to parse, but we would also have a major conversion and education problem on our hands (and I'd probably get tarred and feathered by irate C programmers). I consider the type system of C++ far more important than the grammar (and similarly for any other language). The class specific parts of the C++ syntax is clean and the grammar complexity is primarily a problems for implementors; not users. Much of the complexity in C++ is inherited (sic) from C. I consider it worthwhile to keep this complexity in the language to ease the transition to C++ from traditional languages, to allow re-use of C libraries and tools, and to guarantee that no feature that is essential to get work done in C was left out in C++ due to ignorance or misguided paternalism on my part. Whatever the complexity/simplicity of C++ is, it has been sufficient for tens of thousands of programmers to learn C++ well enough to get their jobs done despite the relative lack of educational material, support, and C++ specific expertise. The first two of these problems have been largely remedied now, the third will remain until C++'s growth rate decreases from exponential. There are several sources of C++ implementations. If you don't trust commercial sources, you can try GNU; if you don't trust GNU, you can try commercial sources; if you don't really trust either you can hope that the many sources will keep each other honest. For libraries, tools, and environments there are additional academic sources. C++ is designed as a traditional programming language in the sense that there is a clear distinction between the language itself, the system in which it runs, and the tools used to create programs. This has the benefit that you get a choice of programming development style, a choice of system interfaces and libraries. In particular, it allows a very low minimum of systems size and run-time support size. The snag is that one cannot expect `one standard system' common to all users. My opinion is that the world is far too large for that to happen anyway (for any successful general-purpose language). We will, however, see national-, regional-, corporate-, industry-, etc. wide standards and we have the beginnings of a C++ tools and libraries industry. C++ as a plain language delivers only a fraction of the benefits of a complete C++ environment and a complete set of libraries. That was clearly understood from the beginning. Even in standard environments such as UNIX, MS/DOS, VMS, etc. C++ provides benefits over more traditional language for a wide range of projects. More specialized and supportive programming environments are now becomming available starting with ParcPlace's Cynergy. An important aspect of C++ is its ability to be used in a mixed language environment. Not only can C++ functions call C, Fortran, etc. functions without overhead; the opposite is also the case. Pointers to C++ object can where necessary be passed to and used directly from functions written in other languages. Similarly, C++ can handle data layouts from other languages in the same way C can. This makes co-existence of C++ and other languages relatively easy, allows C++ to be used to build libraries for other languages, and allows a gradual introduction of C++ into an organization. C++ follows the C tradition in trusting the programmer and in not attempting to force one specific programming style or design method on people. C++ provides much stronger static checking than does C and allowes a far greater range of ideas to be expressed directly in the language - thus making them ameanable to checking and manipulation by tools - than does C (and most other traditional languages for that matter). However, these (user-imposed) rules can always (explicitly) be broken when necessary. The importance of this is an absense of arbitrary and absolute limits. There is a wide variety of programming styles and design approaches that each are valid in particular environments (if not necessarily universally). There are support for several in C++. The freedom for programmers and designers this implies is of course a source of complexity. In my view that complexity is necessary and a sign of maturity. Had the language contained support for only a single style then programmers who (often for good reasons) wanted to use another would have been left without any help from the language and its type system; or worse been left with a set of language features that was explicitly designed to prevent the supposed misuses. I feel that a calm, levelheaded, and often slow approach is needed to get data abstraction, object-oriented programming, etc. and their associated design approaches into widespread use. Requiring an almost religious conversion and a total change of work style of all users is not acceptable to most organizations. C++'s support of a range of style within a single type system and syntax is important for this transition.
bs@alice.UUCP (Bjarne Stroustrup) (06/14/89)
Part of C++'s complexity comes from its abilility to deal with objects directly. In most `object-oriented language', including Simula and Eiffel (I believe), an object of a class must be allocated on the free store and manipulated through a pointer (an implicit pointer, in the case of Eiffel). This has several effects, some beneficial, some not. The beneficial effects of dealing with object only through pointers, such as minimal recompilation after changes to the class declaration, can be achieved in C++ for specific classes by NOT allocating static, automatic, or member objects of those classes and avoiding the use of inlines for their functions. Tools, such as compilers and programs calculating minimal recompilation must be alert to these possibilities. Not having automatic, static, and member objects (as in Simula, Smalltalk, etc.) have an obvious cost in allocation and deallocation. It also implies a storage overhead of a pointer per object and a run-time overhead of at least one memory reference per access to such an object. In presentation to IFIP WG2.4 in 1984 Karel Babcicky estimated the cost of NOT having static and automatic objects of class types in Simula to a factor of two in run-time. His estimate was based on measurements of Simula programs. Karel was in charge of Simula maintenance for the Norvegian computing center for 10 years. The absense of automatic, static, and member objects simplifies garbage collection but also causes a greater need for it. Having member objects in C++ (rather than simply having an object be a set of pointers to sub-objects implies a nice compact storage layout and a minimal storage allocation de-allocation overhead. It is easy to underestimate the effects of these `little' differences in raw (i.e. low-level) efficiency and deficiencies in these areas may be alleviated by gains in overall program organization. However, I have seen no evidence for systematic compensatory gains of this kind compared to C++ in other languages and the absense of low-level run-time efficiency and data compactness definitely leads to C, assembler, and Fortran use. People who refer to C++ as `an object-oriented assembler' often miss the point. C++ is - among other things - really meant fit that description. It was designed to be able to fill that role too. Allocation of objects on the free store can lead not only to inefficiency, but also - in languages where the inderiction is implicit - to a noticeably `discontinuity' in the semantics of assignment. Built in types have copy semantics (e.g. a = b gives `a' the value of `b' if `a' and `b' are, say, ints) whereas user-defined types have pointer semantics (e.g. a = b makes `a' refer to the same object as `b' - not a copy of that object - if `a' and `b' are, say, complex variables). In C++ copy semantics is used for both built-in and user-defined types. Pointer semantics for user-defined types can be implemented by overloading the assignment operator.
bs@alice.UUCP (Bjarne Stroustrup) (06/14/89)
C++ is not simply a set of features grafted onto C. The C++ type system provides coherent checking of all expressions. This system can - when necessary - be broken by explicit use of casts or explicit use of the ellipsis (...) in a function declaration. The simple system of built-in types and standard onversions can be augmented by user-defined types (classes) and user-defined conversions so that new types with essentially the same status as the built-in ones can be provided. The general idea of these mechanisms (classes and operator overloading) is to make C++ extensible but not mutable. It is not possible to, say, redefine + to mean subtraction for integers, though a programmer (with a warped sense of humor) can define his/her own INT class where + means subtraction. Where user-defined types are used ambiguity control is used to make sure that ambiguities are either resolved or reported as errors at compile time. Similar ambiguity control is used for name lookup where multiple inheritance is used. A C++ program consistes of many separately compiled parts. Consistency of the type and name usage is ensured by the use of header files containing the sets of declarations specifying interfaces. In release 1.*, of C++ there was no check on the consistency of the use of these interfaces. In 2.0, consistency is checked at link time.
marti@ethz.UUCP (Robert Marti) (06/15/89)
In article <9474@alice.UUCP>, bs@alice.UUCP (Bjarne Stroustrup) writes: > Should any of this increase your interest to the point where reading a > textbook seems worth the effort here is a selection (in chronological order > more or less): > [ ... ] > Berry, John: "The Waite Group's C++ Programming" [ ... ] > Pohl, Ira: "C++ for C Programmers" [ ... ] > Dewhurst, Steve and Stark, Kathy: "Programming in C++" [ ... ] > Lippman, Stan: "A C++ Primer" [ ... ] > [ ... ] Can anybody out there provide further info on any of these books? I am especially interested in how they cover the issue of object- orientation in C++, for example, different approaches to set up class hierarchies for various uses (tradeoffs in building container classes comes to mind). I'd also like to know which of these books are based on release 2.0 of C++. Of course, I'd especially appreciate the opinions of Bjarne Stroustrup, Andy Koenig and others involved with the C++ design and implementation efforts, but they may be wary of antagonizing the respective authors ... -- Robert Marti Phone: +41 1 256 52 36 Institut fur Informationssysteme ETH-Zentrum CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti
rpj@mcc.com (Rich Johns) (06/16/89)
Other good sources of information about C++ are `The C++ Report' (a newsletter)
and Andrew Koenig's C++ column in the Journal of Object Oriented Programming.
How long has Andrew Koening's C++ column been running? I might want to
track down back issues of the Jouranl of OOP. Who distributes 'The C++
Report'? How does one get on a mailing list? Actually, a better initial
question is: What is the flavor of 'The C++ Report'?
Thanks.
Rich Johns, MCC CAD Program | 3500 W. Balcones Center Dr., Austin, TX 78759
ARPA: johns@mcc.com | Phone: [512] 338-3714
UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!johnsrbm@cbnewsm.ATT.COM (robert.murray) (06/16/89)
In article <1271@ethz.UUCP>, marti@ethz.UUCP (Robert Marti) writes: > > Berry, John: "The Waite Group's C++ Programming" [ ... ] > > Pohl, Ira: "C++ for C Programmers" [ ... ] > > Dewhurst, Steve and Stark, Kathy: "Programming in C++" [ ... ] > > Lippman, Stan: "A C++ Primer" [ ... ] > Can anybody out there provide further info on any of these books? The June, 1989 issue of The C++ Report includes a review of Ira Pohl's book. I expect reviews of the other books to appear in future issues. Rob Murray AT&T Bell Labs also Editor, The C++ Report
ark@alice.UUCP (Andrew Koenig) (06/16/89)
In article <1234@cadillac.CAD.MCC.COM>, rpj@mcc.com (Rich Johns) writes: > How long has Andrew Koening's C++ column been running? My column has appeared in every issue of the Journal of Object-Oriented Programming since its inception. > Who distributes 'The C++ Report'? It's published by the same people who publish the Journal of Object-Oriented Programming. -- --Andrew Koenig ark@europa.att.com
ark@alice.UUCP (Andrew Koenig) (06/16/89)
In article <1271@ethz.UUCP>, marti@ethz.UUCP (Robert Marti) writes: > > Berry, John: "The Waite Group's C++ Programming" [ ... ] > > Pohl, Ira: "C++ for C Programmers" [ ... ] > > Dewhurst, Steve and Stark, Kathy: "Programming in C++" [ ... ] > > Lippman, Stan: "A C++ Primer" [ ... ] > > [ ... ] > Can anybody out there provide further info on any of these books? I have not read the Pohl or Berry books, do not know the authors, and therefore have no opinion of them, good or bad. I have carefully read an early draft of Lippman's book. That draft gives me every reason to believe that the final version (which I have not yet read) will be first-rate. I haven't read Dewhurst and Stark yet, but I've seen other work by them; on that basis I would expect their book to be first-rate as well. I believe Dewhurst and Stark assumes that you already know C well; Lippman assumes that you know something about programming but not necessarily C. Lippman is definitely based on C++ 2.0; I assume Dewhurst and Stark also used it as their basis. Lippman's book is more than twice the size of Dewhurst and Stark's; that will bias some people toward one and some toward the other. -- --Andrew Koenig ark@europa.att.com
dmg@ssc-vax.UUCP (David Geary) (06/17/89)
In article <1271@ethz.UUCP>, Robert Marti writes: In article <9474@alice.UUCP>, bs@alice.UUCP (Bjarne Stroustrup) writes: + Should any of this increase your interest to the point where reading a + textbook seems worth the effort here is a selection (in chronological order + more or less): + [ ... ] + Berry, John: "The Waite Group's C++ Programming" [ ... ] + Pohl, Ira: "C++ for C Programmers" [ ... ] + Dewhurst, Steve and Stark, Kathy: "Programming in C++" [ ... ] + Lippman, Stan: "A C++ Primer" [ ... ] + [ ... ] + Can anybody out there provide further info on any of these books? + I am especially interested in how they cover the issue of object- + orientation in C++, for example, different approaches to set up + class hierarchies for various uses (tradeoffs in building container + classes comes to mind). I'd also like to know which of these books + are based on release 2.0 of C++. + Of course, I'd especially appreciate the opinions of Bjarne Stroustrup, + Andy Koenig and others involved with the C++ design and implementation + efforts, but they may be wary of antagonizing the respective authors ... Well, I'm not Bjarne Stroustrup or Andy Keonig, but I have read the following books: Stroustrup, Bjarne: "The C++ Programming Language" Berry, John: "The Waite Group's C++ Programming" Lewis & Pinson: "Object Oriented Programming and C++" Here are some subjective opinions: Stroustrup, Bjarne: "The C++ Programming Language": This book is written very much in the style of "The C Programming Language" by K&R. It is quite terse and to the point. As with K&R, you will get the most out of this book if you are an experienced programmer. Of course, this book is "The Book", meaning "the" reference for C++. This is the book I pick up when I want to know "is ... legal in C++?". Coverage of OOP: I was suprised to find that BS does not extol upon the virtues of OOP. C++ seems to be presented more as simply a "better C". BS does show the benefits of OOP using C++, but they are scattered throughout the book, and the idea of OOP is not consolidated. For example, on page 213, we find: "That style of programming is often called object based or object oriented..." (Notice the page number). You'd want this book if: You are an experienced (preferably C) programmer, and would like a good reference to the language. You should already understand OOP, and the benfits to be obtained from OOP, as they are not clearly spelled out. Berry, John: "The Waite Group's C++ Programming": This is my least favorite of the three. The code is ridden with bugs, and C++ is not covered in depth. I found the treatment of derived classes and inheritance to be somewhat confusing. Coverage of OOP: In this aspect, the book seems only slightly better than BS. John Berry discusses modularity and data hiding in C, by using an example in C, and then proceeds to show how modularity and data hiding are much better supported in C++ by rewriting the example in C++. However, nowhere in the book does JB discuss the virtues of OOP at length. You'd want this book if: You know next to nothing about C++, and want a decent intro to the language. Don't expect a thorough treatment of the subject, or expect to gain any valuable insight into OOP techniques. Expect to be annoyed by bugs throughout the code examples. Lewis & Pinson: "Object Oriented Programming and C++": (Disclaimer: I'm about 1/2 through this one) Well, this book is the best of the three (IMHO). The book (as it's title suggests) presents OOP concepts well. However, treatment of derived classes and inheritance seems to be somewhat lean. This book, more than any of the 3, contains A LOT of code. There is a chapter on Baseline classes that shows generic linked lists, etc. The book also does not attempt to present the C++ language in a complete manner. For instance, a few times in the book the reader is urged to study Stroustrup's book for a more thorough explanation of certain topics. I also am not completely enamored with the code examples given. Baseline classes left much to be desired IMHO. Coverage of OOP: The best of the 3, OOP and its benefits are discussed at length, and one gets a good understanding of OOP. One technique that I think is useful is comparing C++ code to similar code written in Modula-2, and showing the benefits of OOP in C++ as opposed to "structured" Modula-2. You'd want this book if: You already know most of the basics of C++, and are interested in the OOP aspect of the language. I wouldn't recommend this book for the beginning C++ programmer. This book should be read after the reader has a cursory knowledge of the language. Summary: Get Stroustrup's book for a reference. Get Berry's book if you feel like wasting a little money, and know nothing about C++. Get Weiner and Pinson if you want to explore the OOP features of C++ more. I would buy all of them all over again (with the possible exception of Berry's). However, I think that the best resource one can find for info about C++ is right here. Just as the Wizard of Oz told Dorothy: "You've had the slippers on all the time." OSTTE. None of the books presents topics in the depth they are discussed here on the net. Oh, BTW, none of the books mentions features present in 2.0. None of the books mentions multiple inheritance, except to say that C++ does not support it. However, I have heard that BS will be coming out with a revised version of "The C++ Programming Language". -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, Seattle ~ ~ "I wish I lived where it *only* rains 364 days a year" ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
shrum@hpfcdq.HP.COM (Ken Shrum) (06/19/89)
> > Berry, John: "The Waite Group's C++ Programming" [ ... ] > > [ ... ] > Can anybody out there provide further info on any of these books? Yesterday I scanned through a copy of the above while at the bookstore. I didn't go past page 100, didn't read it exhaustively, but instead just looked for how well the book presented C++. I found that the examples tended to have many typographical errors, mostly misspelled variable names. Variable and function names were not referred to consistently (e.g. get_var versus get_variable). The examples also had some semantic errors (1 based arrays rather than zero, off by one errors) and a few that were difficult to classify (see below). There was also a tendency to have confusing examples, for instance: foo(int x, y) { int y; ... } and class new_foo { ... }; class foo : new_foo { new_foo(...) } where foo::new_foo seems to be intended to be the constructor for foo. In addition, the operators << and >> are described as being "new" to C++ as compared to C, and are referred to in the index as the "output" and "input" operators respectively. No reference is given to these as being the left and right shift operators. The above is not intended to be an exhaustive review of the book, but only reflects impressions gathered over half an hour. Ken Shrum
pcg@aber-cs.UUCP (Piercarlo Grandi) (07/22/89)
In article <9476@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes:
The complexity of C++ reflects this range of uses and requirements.
Given this, estimates of C++'s complexity is often greatly inflated.
Well, well. C++ is a nice job, but but... Several "features" seem to have
been put in because they *looked* right. A much too experimental attitude,
let's say. Example: visibility rules. They are not well understood, or
at least there is no consistent model of them, and there are many dark spots.
It would be trivial to design a syntax for C++ that was noticeably
easier to parse,
Ah no! You should have written "It would HAVE BEEN trivial ...". It can be
argued that some ambiguities and problems of the C++ syntax descend from
mistakes or at least questionable laxity on your part. Example:
a b(c);
This is fairly ambiguous. Old C hands know that C itself once allowed a
similar syntax
a b { c };
that was dropped in favour of the
a b = { c };
syntax because the former could confuse the compilers (as said in K&R and/or
the V7 Unix C docs). I understand that
complex i(0,1);
looks neater than
complex i = complex(0,1);
but the latter is amply sufficient... Why ever was a variant of the ambiguous
initialization syntax without '=' crept back into the language when it had
been expunged precisely because of ambiguities?
This is the most glaring example, in that a (arguable) *mistake* has been
actually *reintroduced* in the language. The other ambiguities or problems
are also often fairly pointless, in that their benefit is not great (e.g.
automatically typedef'ed class and struct names, casts that look function
calls or declar), and they have obvious counterindications (ask Michael
Tiemann...).
but we would also have a major conversion and education
problem on our hands
Yes, because it is now too late to rectify mistakes or pointlessly
sophisticated syntax features. Too many users depend on them; and users
outnumber compiler writers by a wide margin...
(and I'd probably get tarred and feathered by irate C programmers).
What does this mean? That to make C++ syntax simpler and less ambiguous
you would want to change C syntax, because it is C that gives you problems?
If so (as the parts I have not commented on of this article seem to imply),
I beg to differ. The underlying C syntax and semantics have their warts (e.g.
"typedef", "enum", "int;", bit fields that may be signed or unsigned at the
compiler's whim even if explicitly declared "int" or "unsigned", ...), but
they have proven livable with.
C++ *adds* to them, and sometimes with fairly gratuitous incompabilities
(e.g. typedef). It is not unusable for this, far from it, but a bit of the
sense of grace that emanates from C has been lost.
Finally my point on the Eiffel/C++ controversy: I use C++ because I am a
systems person, and even if Eiffel has very clever technology, it simply
cannot go where C++ can. The claim that C++ goes wherever C could have gone
(in both lowly hackerism and tightness) is substantially true. Eiffel seems
an higher level language, somewhat intermediate between C++ and Smalltalk.
But the main difference is that C++ has been designed *without* the backing
of a comprehensive philosophy of object orientedness, but rather in a
pragmatic, trial-and-error fashion (and it shows). Eiffel is the result of
specific conscious high brow analysis of OO program development (even if
adjustments are being made) from time to time, and as such has its
attractions to those that are persuaded by it.
I tend to agree to the Modula-2/C (less worrying to Eiffel advocates than
the Pascal/C one... :->) analogy for Eiffel/C++; the C style of language is
a sharper tool than most others, and if you can handle its (optional) unsafe
features you can go a long way.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukscs@vax3.iti.org (Steve Simmons) (07/23/89)
In article <2727@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: >In article <9474@alice.UUCP>, bs@alice.UUCP (Bjarne Stroustrup) writes: >+ Should any of this increase your interest to the point where reading a >+ textbook seems worth the effort here is a selection (in chronological order >+ Pohl, Ira: "C++ for C Programmers" [ ... ] >+ [ ... ] I'm part-way thru reading the Pohl book, and on the whole am pleased. Like his book on C ("A Book On C", written with Al Kelley) it's fairly low-level but clean and consise. It clearly does not go into great depth, but is a very good start for the audience indicated in the title. I use the Kelley/Pohl book when teaching C, but supplement it with Harbison and Steele. From what I've see so far, "C++ For C Programmers" would pair nicely with Stroustrup for teaching C++. Caveat: I don't know C++ nearly well enough to teach it, so take the appropriate grain of salt. Steve Simmons Just another midwestern boy scs@vax3.iti.org -- or -- ...!sharkey!itivax!scs "Think of c++ as an object-oriented assembler..."