Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!bs From: bs@alice.UucP (Bjarne Stroustrup) Newsgroups: net.lang Subject: Re: C++ and Modula-2 (and something about data abstraction) Message-ID: <4531@alice.UUCP> Date: Thu, 7-Nov-85 11:14:27 EST Article-I.D.: alice.4531 Posted: Thu Nov 7 11:14:27 1985 Date-Received: Fri, 8-Nov-85 07:47:44 EST Organization: Bell Labs, Murray Hill Lines: 87 >From: rmarti@sun.uucp (Bob Marti) >Newsgroups: net.lang >Subject: Re: C++ and Modula-2 (and something about data abstraction) > Message-ID: <2958@sun.uucp> > > In response to Bjarne Stroustrup's message <4500@alice.UUCP>: > >Let me make a few final remarks in this ongoing discussion about the relative >merits of C++ versus Modula-2. There is, of course, no such thing as a really final remark. >(1) You still don't seem to have gotten my point that I was comparing Modula-2 > to C rather than C++. You jumped on my C++ note to pick on C, so I jumped on yours to pick on Modula-2. > I do get your point, though, namely that you think > C++ is way better than Modula-2. Let's hope you are right! Maybe you > could write a paper entitled "Why Modula-2 is not my favorite programming > language" :-) I could be a nice paper. Maybe in a year's time someone will produce a good C++ vs Modula-2 paper based on experience with both. I shouldn't be the one to write that one, though. >(2) If you try a little harder, you might even find definitions for the terms > data abstraction etc. which only fit C++ and no other language :-) I am of the opinion that terms such as "data abstraction" is often defined in such a way that it is far too easy to claim that a language supports it. In particular, you often see definitions so that "data hiding", "data abstraction", and "object-oriented programming" becomes near synonymous. This, I believe, is often the effect of overenthusiasm on behalf of some language (there is a certain perverse logic at work here: "DA is good" and "Language X is good" therefore "language X supports DA"). It is also quite hard to avoid defining "data abstraction" in terms of facilities in a specific language. Niklaus Wirth, for example, comes very close to defining "data abstraction" as "opaque export" (his book, 2nd edition, page 82). This very nearly makes "Modula-2 supports data abstraction" a tautology. > Moreover, in contrast to your opinion, it *is* possible to declare > variables of an opaque type which are only accessible using a specific > set of procedures declared in the same module. You can do that, and handle a very limited set of cases (your note below), but there is a serious snag here. Variables of an opaque type can be copied freely (you don't have to define a copy operation in the module, assignment works by default - correct me if I'm wrong, my Modula-2 compiler has become uninstalled again). This implies, that what you have got is a facility for defining pointers and for defining types for which bitwise copying is ok. The former is of little additional value (given modularity/data-hiding), and it strongly resembles C's rule that you can have variables of type "struct X *" even where the definition of "struct X" is not available. In other words, if data abstraction in Modula-2 is use of opaque types that are really pointers (as recommended by Wirth), C too supports data abstraction, and in nearly exactly the same way. I find that a hard to swallow. If not, the case for Modula-2 supporting data abstraction rests on the ability to opaquely export types that (1) are not pointers, and (2) can be freely copied. C's ``data abstraction facilities'' would be strictly equivalent to Modula-2's had it not been for pointer arithmetic. > The fact that, in the current implementations of Modula-2, variables of > an opaque type are typically restricted to a size of 1 or 2 words which > forces you to use a POINTER TO RECORD ... representation is just that: > An implementation restriction. It is a very hard restriction to lift without causing other problems, though, and as long as it is enforced I don't think one can claim that Modula-2 supports data abstraction (at least not without making the same claim for C, and then the meaning of "data abstraction" has been eroded so far as to be meaningless). Both possess a rudimentary facility that makes a limited form of data abstraction just barely possible. > As far as "notational conveniences" are concerned, you are > of course right again, but as you say, they are just conveniences ... One of the hardest things to do is to live without conveniences you have gotten used too. >(3) As far as the date of appearance of Modula-2 is concerned, I was absolutely > baffled to find that your quote from Wirth's book checked out. All I can > say is that I was at ETH at the time, that I do have the Modula-2 report > quoted in my last message, and that its publishing date is December 1978. > Why Niklaus Wirth is stating that the language's definition was published > in March 1980 is completely beyond me. I do admit that I was wrong about > the public availability of the compilers. Maybe he'll fix the publication date in the next edition. - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill) PS In case someone missed the main points in the details of the discussion: C++ supports data abstraction and object-oriented programming. C++ is available (commercially and educationally).