wsmith@m.cs.uiuc.edu (02/10/89)
Why is it so important that C++ be compatible with C at the source level? I think this restriction makes it much more difficult to parse or evolve. I think it is time for C++ to be emancipated from backward compatability with C at the source level. Bill Smith uiucdcs!wsmith wsmith@cs.uiuc.edu (If this topic has generated any previous polite discussions in the past, save your breath and just send me a transcript...)
ark@alice.UUCP (Andrew Koenig) (02/11/89)
In article <4800051@m.cs.uiuc.edu>, wsmith@m.cs.uiuc.edu writes: > I think it is time for C++ to be emancipated from backward compatability > with C at the source level. Interesting thought. What incompatibilities would you think would be worthwhile having? What about incompatibility with previous versions of C++? C++ is already somewhat incompatibile with C, of course. The question is: under what circumstances is is worthwhile for it to become more so? -- --Andrew Koenig ark@europa.att.com
gore@eecs.nwu.edu (Jacob Gore) (02/13/89)
In article <4800051@m.cs.uiuc.edu>, wsmith@m.cs.uiuc.edu writes: > I think it is time for C++ to be emancipated from backward compatability > with C at the source level. / comp.lang.c++ / ark@alice.UUCP (Andrew Koenig) / Feb 11, 1989 / >Interesting thought. What incompatibilities would you think >would be worthwhile having? Change the declaration syntax. Can someone name another language for which people write "declaration interpreter" tools? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore
muller@munnari.oz (Paul Muller) (02/13/89)
In article <4800051@m.cs.uiuc.edu>, wsmith@m.cs.uiuc.edu writes: > > Why is it so important that C++ be compatible with C at the source level? > > I think this restriction makes it much more difficult to parse or evolve. > > I think it is time for C++ to be emancipated from backward compatability > with C at the source level. > (If this topic has generated any previous polite discussions in the past, > save your breath and just send me a transcript...) I gather from what you are saying that the downward compatibility of the C++ language with its PREDECESSOR is indesirable? That seems to me to be the metal equivalent of walking backward for Xmas..... I gather Bjarne's whole idea was to EXTEND the language in a way that would allow for the traditional C syntax and tersness, yet embody the spirit of many of the OOP concepts (classes, inheritance, etc). I admit to being new to this idea, and for the greater part still program in pure C, though I like the idea of slowly extending my existing code, QUICKLY and WITHOUT a complete rewrite. I can then examine the code and find areas where the new language elemants of C++ would allow the code to be more functional or even just plain readable. If people wanted a language that shed any/all of the so called 'restrictions' of C, they would use Smalltalk. (for those concerned enough to possibly act on that last statement, I used Smalltalk as a quick and dirty example for another OOP) I think you should look at it from the point of view that it is C++ not { while(idiosyncrasies(spel?)) { C++ } } if that were to continue for every complaint about the language you would end up with either an unweildly and difficult language to impement and use, or a language that is so far removed from its namesake that it would only lead to confusion as to its purpose/use. I am sorry if I got to high on my soap box, but I feel that the problem with the C++ language is that people like to play around with the definition to suit them, hoping that because of the relative 'newness' of the language, people will conform to their ideas and create yet another language, and I just couldn't stand buying YAC (yet another compiler) :-) Is Bjarne around to comment? Is there currently any gorverning body (eg ANSI) that are trying to freeze the language for long enough to let Microsoft get a version out :-) Paul PS I use Zortech C++ for those curious. Oh and Walter, if you're reading, I was shipped a free update, it arrived Friday (1.07). Is the new debugger any good?
leech@zeta.cs.unc.edu (Jonathan Leech) (02/15/89)
In article <2677@munnari.oz> muller@munnari.oz (Paul Muller) writes: >In article <4800051@m.cs.uiuc.edu>, wsmith@m.cs.uiuc.edu writes: >> I think it is time for C++ to be emancipated from backward compatability >> with C at the source level. >I gather from what you are saying that the downward compatibility of the C++ >language with its PREDECESSOR is indesirable? Such downward compatibility does not exist for many complex old-C programs, for both language and implementation (cfront) reasons. Given that old-C compatibility is already incomplete, it's reasonable to relax compatibility restrictions more significantly if it allows desirable new capabilities in C++. -- Jon Leech (leech@cs.unc.edu) __@/ "Totally bounded: A set that can be patrolled by a finite number of arbitrarily near-sighted policemen." A. Wilonsky, 1978
orr@cs.glasgow.ac.uk (Fraser Orr) (02/17/89)
In article <8902@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >C++ is already somewhat incompatibile with C, of course. The question >is: under what circumstances is is worthwhile for it to become >more so? If C++ is already somewhat incompatible, would it not be wise to leave C syntax behind entirely? Two reasons why, 1) I think most people would agree that a great deal of it is pretty crummy (do I presume to much? does anyone actually like the "for" loop syntax?) 2) by having it so close to C syntax, one might easily be decieved into thinking that it is the same, thus leading to all sorts of errors. If your going to create a new language, either it has got to be 100% (with the exception of keywords and things of that kind perhaps) compatible, or VERY different. Any comments, ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
hall@kayak.cis.ohio-state.edu (john hall) (02/24/89)
In article <2438@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk (Fraser Orr) writes: >1) I think most people would agree that a great deal of it is pretty >crummy (do I presume to much? does anyone actually like the "for" loop >syntax?) I like the C syntax, including the "for" syntax. What I can't stand is Pascal syntax -> begin/end's drive me nuts. My main attraction to C++ is that it has a C subset. The extentions are all very natural, and intuitively obvious to a good C programmer. C++ is the better language. ( Better than C, Pascal, Modula 2, Ada, or any of those other sissy pinko languages :-). At least for what I use it for. I do agree that most people new to C++ write C programs in C++, but remember that OOP is a different way of THINKING about problems. It takes a while to get used to.
wgh@ubbpc.UUCP (William G. Hutchison) (02/24/89)
In article <2438@crete.cs.glasgow.ac.uk>, orr@cs.glasgow.ac.uk (Fraser Orr) writes: > In article <8902@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: > >C++ is already somewhat incompatibile with C, of course. The question > >is: under what circumstances is is worthwhile for it to become > >more so? > > If C++ is already somewhat incompatible, would it not be wise to leave C > syntax behind entirely? Two reasons why, > 1) [ ... syntax is crummy ] > 2) [ ... similarity to C is deceptive and promotes programming errors ... ] I agree with your criticisms of the syntax of C++, but I am afraid you can't change it in the next few years. If C++ is not a near-superset of C, it will die: there is too much C code to rewrite. Think of Lotus 1-2-3 release 3.0 (if it ever gets released: 3-400K lines?). Once C++ becomes the new de-facto standard, it will be meaningful to talk about (C++)++ [ which I know is now a syntax error! ]. I suggest that C++ cannot become the de-facto standard portable application programming language until (1) UNIX is substantially re-written in C++, and (2) Microsoft releases a C++ with the Microsoft 5.1 features included. -- Bill Hutchison, DP Consultant rutgers!liberty!burdvax!ubbpc!wgh Unisys UNIX Portation Center P.O. Box 500, M.S. B121 Jacobites unite: Scotland Free in '93!! Blue Bell, PA 19424
budd@mist.cs.orst.edu (Tim Budd) (02/24/89)
> >I do agree that most people new to C++ write C programs in C++, >but remember that OOP is a different way of THINKING about >problems. It takes a while to get used to. > Which is why I think Smalltalk or some other OO language is much better than C++. It is not that the language is necessarily better, but that it is sufficiently foreign that users are forced to make a major effort in redirecting their thinking. Far to many bussessness are jumping on the C++ bandwagon thinking it will solve all their problems, when far too many of their programmers will simply continue to write C programs in C++. The unfortunate property of C++, as with C, is that the language doesn't force, or even encourage, you to go in any particularly constructive direction, or to code in any particularly useful style. In Smalltalk, at least, it is very difficult to NOT write code that is polymorphic, reusable, etc etc.
wsmith@m.cs.uiuc.edu (02/25/89)
I think one problem with direct compatibility between C++ and C is bad is
the effect it has on error messages from CC.
This construct was caused by a missing semicolon on line one, but
the first error message refers to line 4.
1: int foo( int ) // ;
2: int bar;
3: int another_function(int c)
4: {
5: }
The intent of this construct was to declare function foo for later use, but
the semicolon was omitted. If the parser did not attempt to give a
warning about old-fashioned parameter declarations, it would find an
error on line 2 which is much closer to the original problem. Converting
function headers to C++ standards is not a difficult task so that I don't
think it is too expensive to disallow the old form.
I don't think that semantically there is much problem with maintaining
compatibility, but that for the compiler writer, excessive syntactic
compatibility makes the compiler more difficult to write well.
Bill Smith
wsmith@cs.uiuc.edu
uiucdcs!wsmithhardin@hpindda.HP.COM (John Hardin) (02/25/89)
>If C++ is already somewhat incompatible, would it not be wise to leave C >syntax behind entirely? Two reasons why, > >1) I think most people would agree that a great deal of it is pretty >crummy (do I presume to much? does anyone actually like the "for" loop >syntax?) > >==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) ---------- I'm surprised to find that anyone does NOT like the C "for" loop syntax! Keeping the loop initialization, step, and termination test in one place seems like a nice feature. The main target for change in C, IMHO, is the variable declaration syntax. Luckily I have a utility that will take English-like explanations of what I want (e.g., pointer to an array of 5 pointers to functions returning doubles) and output the C syntax. It shouldn't be too difficult to include in C the ability to read this pseudo- English directly (as an option, of course). John Hardin, hardin%hpindda@hplabs.hp.com
henry@utzoo.uucp (Henry Spencer) (02/25/89)
In article <9048@orstcs.CS.ORST.EDU> budd@mist.UUCP (Tim Budd) writes: >>... OOP is a different way of THINKING about >>problems. It takes a while to get used to. >> >Which is why I think Smalltalk or some other OO language is much better >than C++. It is not that the language is necessarily better, but that it >is sufficiently foreign that users are forced to make a major effort in >redirecting their thinking... Of course, that extra effort guarantees that many fewer people will be interested. C++ permits but does not demand the change in thinking. This means that one can program in C++ without ever bothering to change, but it also means that one can make the switch gradually, without a major up-front startup overhead. This is not a trivial issue for people whose primary attention has to be on getting code out the door; for them the alternative to a gradual transition is no transition. As usual, C++ opts for practicality over theoretical cleanliness. -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
eric@snark.uu.net (Eric S. Raymond) (02/25/89)
Warning: mild soapboxing by a confirmed C partisan follows. In <2438@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk (Fraser Orr) writes: > 1) I think most people would agree that a great deal of it is pretty > crummy (do I presume to much? does anyone actually like the "for" loop > syntax?) C's for() construct is the most powerful available in any real-world language. If you know what you're doing you can write things like linked-list walkers in a way that packages all the traversal logic into the (;;) part. I like having that power, and am *not* interested in efforts to `fix' the construct if they would involve restricting it to some `safe' pascal-oid step-by-n thing. > 2) by having it so close to C syntax, one might easily be decieved into > thinking that it is the same, thus leading to all sorts of errors. If > your going to create a new language, either it has got to be 100% (with > the exception of keywords and things of that kind perhaps) compatible, > or VERY different. <mild sarcasm on> Uh huh. I suppose you also think that either a) English ought to be frozen as it is now, or b) we ought to junk it tomorrow and switch to Esperanto. <mild sarcasm off> In the real world, languages evolve. And human beings (even programmers) are pretty good at coping with such changes. C itself is a rather differently- flavored language now than it was in 1976, having moved steadily towards a more comprehensive and stricter type system -- and this is good! Those of us who enjoy C and have learned to use it well aren't confused by the changes in it, or by C++, nor are we fazed by the prospect of further evolution. The right thing to do about this kind of process is: lead, follow, or get out of the way. -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (02/28/89)
eric@snark.uu.net (Eric S. Raymond) writes... C's for() construct is the most powerful available in any real-world language. This is almost true, but there's a good reason to change it. Right now, you can't say: for (int i = 0; ....... etc ); for (int i = 0; ....... etc ); because the C++ scope rules follow the C scope rules here. I think this is a major pain in the rear -- I try to restrict the scope of variables as much as possible to reduce possible errors. This is a case where a divergence from C would be useful (and it's not clear to me it would break anything else) -- Dirk Grunwald Univ. of Illinois grunwald@flute.cs.uiuc.edu
bs@alice.UUCP (Bjarne Stroustrup) (02/28/89)
Let me just make a few points about C++, C compatibility, and C++ language evolution: [1] C++ will remain as compatible with C as possible It may even become more compatible than current implementattions are. The cfront implementation is by and large compatible with K&R C. As promised in my book, the C++ definition is now being revised with the view of removing gratuitous incompatibilities with the proposed ANSI C standard. The reason for compatibility is not that C is perfect but that in areas such as expression evaluation and statement syntax C is good enough (my opinion is that though C certainly isn't perfect, it is better than it is often given credit for and better than many suggested `improvements'). There are a couple of hundred thousand programmers that will NOT appreciate having to re-learn the basics to gain a marginal improvement. If we introduce anything genuinely different at this level it is likely to affect the object layout and/or function call mechanism so that link compatibility becomes an issue. Furthermore, since C isn't just going to go away there is the need to maintain many millions of lines of C for many years to come; having compatibility at the function, statement, expression, and object layout levels is important to many people. Dealing with two similar but subtlely different languages on a daily basic is not pleasant. Except for the specific C++ features, C and C++ should be identical in almost all respects and the remaining differences should all be detected by the (C++) compilers. [2] C++ will not change incompatibly or radically. I'm sorry to disappoint the many people that seem to think that C++ can be radically improved by a few quick changes (often changes that is incompatible with both C and C++). C++ may be a relatively new language (only about 5 years of serious use), but C++ is not silly putty and cannot be radically changed without seriously inconveniences thousands of users. Also, if I had wanted to create a language that was radically different from C++ I would have done so. C++ was based on C, uses a compiler based (``strong'') static type checking strategy, and preserves low-level features (and efficiency) by design, not accident. [3] C++ will grow C++ will be enhanced by features such as exception handling and parameterized types, but the growth will be gradual with great concern for compatibility. The things that could affect C++'s usefulness and growth most seriously now are rampant featurism, incompatible implementations, and changes without concern for existing C++ users. [4] C++ is not intented to FORCE people to change. It is intented to allow and encourrage people to learn and to change if and when they want to and at a pace they are comfortable with. Moving from `plain C' style programming to more powerful techniques in stages is possible and for many people the only way. This is not the only way of doing things, it is not meant to be. A more rapid change of style is possible with C++ and there are no shortage of `pure object-oriented' languages and systems for people who don't like compromises, static type checking, or whatever. As far as I can see people condemming C++ for not forcing programmers to use `object-oriented programming' mis a key point about C++ and some suffer from dangerous paternalistic tendencies. They might also ask themselves whether their favorite language/system today have more or fewer users because of C++'s growth/acceptance/fame/notoriety. By and large I think C++'s effects on the spread other languages and systems supporting object-oriented programming, etc. have been minimal and positive. [5] Education is the key The key bottleneck for C++ use is education. It is also the hardest to overcome. C++'s growthrate ensures that. Major problems with education are the lack of a sufficiently well defined standard, the relative lack of tools for novices, and the widespread tendency of not accepting C++ for what it is but considering it as an imperfect copy of something else. The two former problems are rapidly being remedied the third could be critical. C++ is not (just) C C++ is not Modula2 with a funny syntax C++ is not Ada minus Army backing C++ is not a crippled Smalltalk C++ is not yet another dialect of Lisp For people wondering what C++ actually is and what C++ might become, I can recommend the proceedings from the two USENIX C++ conferences. My opinions and those of dozens of others can be found there. [6] We are working on a preliminary to standardization. As I have mentioned here and elsewhere before, we need stability and a wide agreement on the definition of C++. To this end I'm working on a revised language definition and individuals from a couple of dozen different organizations are helping me. The aim is a good language specification by August. Such a language specification can be a good basis for a more formal (and necessarily much longer) standardization process. This process - and also the ANSI standardization of C - may introduce incompatibilities (with early C++ implementations). These incompatibilities are neccesary (to avoid implementation dependencies in the language specification and fights with ANSI) and hopefully (and apparantly) minor. These problems should be faced sooner rather than later to minimize the inconvenience of users. [7] Tools and libraries are fertile areas for improvements C++ has been defined as a classical language with only minimal standard libraries, NOT as an integrated system. This is both a strength and a weakness, but was certainly deliberate. Many are now working on creating libraries, tools, and complete programming environments for C++. This is good and it was expected. This will allow a wide array of techniques to be applied to help programmers in addition to what the language itself provides. I expect the language features, libraries, tools, and environments to have at least additive effects for the programmers. Some of these tools etc. will support some programming styles, some design methods, some philosophies, etc. better than others, some will help novices and some experts. My hope and expectation is that the relative diversity of style and opinion that C++ accomodates or even encourrage will be reflected in these tools, etc.
orr@cs.glasgow.ac.uk (Fraser Orr) (03/01/89)
Silly comment, with a serious point at the end. In article <36818@tut.cis.ohio-state.edu> john hall <hall@cis.ohio-state.edu> writes: >In article <2438@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk (Fraser Orr) writes: >I like the C syntax, including the "for" syntax. >What I can't stand is Pascal syntax -> begin/end's drive me >nuts. Interesting, especially since the word "for" does not convey any hint of itteration, where as "begin" clearly indicates that something (a syntactic block) is about to begin. Are you really in favour of having a meaningless set of keywords? (That is of course a tautological question, since you've already said you like C :^) Of course your going to tell me that {} are so much easier to type, and so much easier to read. I propose that all keywords be eliminated and replaced by stupid symbols ... #(i=0; i<MAX; i++) { $(a[i].val) { j++ ; % ; } ^ & ; } ; A chocolate watch for the first person who can tell me what the above does <^: >My main attraction to C++ is that it has a C subset. The >extentions are all very natural, and intuitively obvious to >a good C programmer. I guess I'm just a bad C programmer, it took me two readings of Stroustrup to get an idea of what was going on, a fair bit more study to get a detailed grip. >I do agree that most people new to C++ write C programs in C++, >but remember that OOP is a different way of THINKING about >problems. It takes a while to get used to. Yup, this is surely an argument for changing the syntax completely, since having the same syntax means you can "do it the old way" so you never get round to properly exploiting the OO technique. As someone pointed out by e-mail, I can go away and use a proper OO language, but it does seems such a waste since the new bits in C++ I quite like, its just the horrible historical hangovers from the chronic crutch of C, that get bug me. ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk
db@lfcs.ed.ac.uk (Dave Berry) (03/02/89)
In article <GRUNWALD.89Feb27133038@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu (Dirk Grunwald) writes: >Right now, you can't say: > > for (int i = 0; ....... etc ); > for (int i = 0; ....... etc ); > >This is a case where a divergence from C would be useful (and it's not clear >to me it would break anything else) It wouldn't be a divergance from C, because C doesn't allow declarations at the start of a for loop. I also have a gripe with the C++ for loop, and that is that you can't say for (int i = 0; int j = 0; ....... etc ); because C uses semicolons to separate the different bits of the for loop. Perhaps C++ could use commas to separate declarations in this case, i.e. for (int i = 0, int j = 0; ....... etc ); This is like an extension of the comma operator, but would probably have to be limited to this part of the syntax to avoid clashes. Dave Berry, Laboratory for Foundations of Computer Science, Edinburgh. db%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!db
nevin1@ihlpb.ATT.COM (Liber) (03/03/89)
In article <GRUNWALD.89Feb27133038@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu (Dirk Grunwald) writes: >Right now, you can't say: > > for (int i = 0; ....... etc ); > for (int i = 0; ....... etc ); > >because the C++ scope rules follow the C scope rules here. I'm not sure what you mean in this instance by "the C scope rules". Since C doesn't allow you to declare variables inside "for" statements, I assume you mean one of the following: a) You can't declare different types of variables within a "for" statement, because of the ambiguity problems with the semicolon. or b) Variables declared inside a "for" statement are visible to the end of the enclosing block, and not just within the "for" loop. (I think this is what you mean, and the following is my reply:) >I think this is >a major pain in the rear -- I try to restrict the scope of variables as >much as possible to reduce possible errors. Personally, I would also like to see the scope restricted to within the "for" loop. To get around this, I either 1) Declare the variable just outside the "for" loop (to emphasize the visibility past the end of the "for" loop): ... //some code int i; for (i=0; ...) ... //body of "for" loop 2) Put braces around the "for" loop (to limit the visibility of the control variable): ... //some code { for (int i=0; ...) ... //body of "for" loop } 3) Combine 1) and 2) (especially useful when declaring more than one variable while still trying to limit scope): ... //some code { int i; for (i=0; ...) ... //body of "for" loop } None of these are faults of C, however. -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (312) 979-4751 IH 4F-410 ' ) ) "I will not be pushed, filed, stamped, indexed, / / _ , __o ____ briefed, debriefed or numbered! My life is my own!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
dms@mcgp1.UUCP (David Stanhope) (03/06/89)
In article <2490@crete.cs.glasgow.ac.uk>, orr@cs.glasgow.ac.uk (Fraser Orr) writes: > Silly comment, with a serious point at the end. > In article <36818@tut.cis.ohio-state.edu> john hall <hall@cis.ohio-state.edu> writes: > >In article <2438@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk (Fraser Orr) writes: [DELETED] > and so much easier to read. I propose that all keywords be eliminated > and replaced by stupid symbols ... > #(i=0; i<MAX; i++) { $(a[i].val) { j++ ; % ; } ^ & ; } ; for (i=0; i<MAX; i++) { if (a[i].val) { j++; break; } else continue; }; > A chocolate watch for the first person who can tell me what the above > does <^: I kinda like your idea. I want my chocolate watch!!
gore@eecs.nwu.edu (Jacob Gore) (03/07/89)
> #(i=0; i<MAX; i++) { $(a[i].val) { j++ ; % ; } ^ & ; } ;
No, no, no. It should read:
i 0 = { i MAX } < { i ++ } { a i [] 'val . { j ++ % } { & } $^ } #
And while we're at it, let's rename the language:
(C/2+(APL+Forth+Lisp+Postscript)/4)+1
...uhm, I mean
C 2 / APL Fourth Lisp Postscript + + + 4 / 1 + +
Jacob Gore Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore