scs@itivax.UUCP (Steve C. Simmons) (09/18/88)
From the first "release" of C outside of Bell Labs to the first commercial C compiler was years. From the first release of C++ to the first commercial compiler was a much shorter period. C++ is going through a much faster "public acceptance" path than C did. In fact, it's faster than any language I can think of except maybe pascal. One of the major problems with Pascal was dialectization (sp?). Everybody had their own features to make up for lacks (whether real or perceived) and everybody did it differently. This lone fact probably did more to stunt Pascal as a portable language than anything else. The same process has already started with C++. There are ads for C++ compilers (well, one) with parameterized types, a feature not (yet) in cfront or g++. Zortech is apparently selling like crazy. Library packages are springing up all over the place, each with it's own set of compiler dependancies. We need to start thinking seriously about standardization. "But the language isn't complete" you cry? True, but only to a limited degree. "But it'll stifle innovation" you say? What's more important, innovation or code reusability? [[hey, cool down. i'm kicking straw men here.]] C managed to live for so long without a standard because there was a de-facto one in K&R. This is not true of C++ *because* of Stroustrup -- he's being very flexible. It's time to start talking about a standards effort. Starting the discussion today means it will be one to two years before we have a real committee, and one to two years before we have a standard. Figure three years from now *at best*. Starting today is not too soon; starting today will not unreasonably stifle the innovation that is under way and will wrap up in the next two years. I will now go and don my asbestos suit! :-) -- Steve Simmons ...!umix!itivax!vax3!scs Industrial Technology Institute, Ann Arbor, MI. "You can't get here from here."
halldors@paul.rutgers.edu (Magnus M Halldorsson) (09/18/88)
In article <255@itivax.UUCP> scs@itivax.UUCP (Steve C. Simmons) writes: > It's time to start talking about a standards effort. Hell no. Allow the designer to continue improve the language without the commercial interests and the rampant featurism of committees. C++ is growing slowly but surely; yes, I'd like to see parametrized classes and incremental compilation soon, but not if it means loss of efficiency or transparity. C++ should remain a 'better C'. Magnus
bright@Data-IO.COM (Walter Bright) (09/19/88)
In article <255@itivax.UUCP> scs@itivax.UUCP (Steve C. Simmons) writes: >It's time to start talking about a standards effort. I am wholly in favor of a standard for C++. The emerging standard for C has immeasurably helped the C programming community. I'd like to see an ANSI C++ standardization effort start after the ANSI C spec is signed off.
jima@hplsla.HP.COM ( Jim Adcock) (09/19/88)
At this point in time what I'd rather see is an agreed upon "subset" of the language that we could expect all "C++" compilers to accept -- while still allowing the various compiler camps to experiment with new features that may prove to be generally useful above and beyond this core set. I'd pretty much like the "agreed upon" core set of the language to be pretty much the stuff that bs has described up through and including multiple inheritence. Let people continue to work on the "unsolved" problems like parameterized classes, multiprocessing, error recovery, memory management, dynamic linking of new classes..... .... and when good solutions to these problems are proven out in various people's compilers then maybe we can begin to include these features in the language at large. Still, one has to wonder if the set of language features really needed to solve "the programming problem" at large isn't a larger set than the average programmer would want to bite off anyway? Which might imply that ultimately C++ compilers might head in the direction of a core feature set, plus optional goodies for people with more specialized needs. Alternately [or in addition to], it might be nice if the various compiler camps could come up with agreed upon definitions of various "levels" of the C++ language so that we could know what major features of the "C++ language" are going to be available to us when we buy a particular vendor's compiler. For example, a "level 1" implementation of a C++ compiler might only support single inheritence, a "level 2" implementation of a C++ compiler might mean that multiple inheritence is supported, "level 3" implementations of the language might support parameterized classes ...... This would allow vendors to offer conforming implementations of "C++" at various levels of sophistication, and customers would then have reasonable expectations and knowledge of what it is they're really buying.
bs@alice.UUCP (Bjarne Stroustrup) (09/20/88)
Steve C. Simmons from the Industrial Technology Institute, Ann Arbor writes > From the first "release" of C outside of Bell Labs to the > first commercial C compiler was years. From the first release > of C++ to the first commercial compiler was a much shorter > period. > C++ is going through a much faster "public acceptance" path > than C did. In fact, it's faster than any language I can > think of except maybe pascal. Yes, that is both nice and scary. > One of the major problems with Pascal was dialectization (sp?). > Everybody had their own features to make up for lacks (whether > real or perceived) and everybody did it differently. This lone > fact probably did more to stunt Pascal as a portable language > than anything else. I am among the ones who think that the main reason for the fragmentation of Pascal was that extensions were needed, but that nobody took it upon themselves to provide ways for needed extensions to find their way into a common language. Until it was too late, too many pretended either that Pascal was perfect or that Pascal was only an educational tool anyway. I don't think we need to worry about those fallacies in the context of C++, but we do need to worry about how we can evolve without language fragmentation. Attempting to freeze the language, say, at the level described in my book would almost certainly guarantee that we will suffer the problems of Pascal to the worst degree. > The same process has already started with C++. There are ads > for C++ compilers (well, one) with parameterized types, a feature > not (yet) in cfront or g++. Ads for a C++ with parameterized types? I haven't seen them. There has been much talk, a little writing, and a few experiments, but I haven't seen an extended C++ for sale. > Zortech is apparently selling like crazy. > Library packages are springing up all over the place, > each with it's own set of compiler dependancies. Nice, Nice, and Bad. > We need to start thinking seriously about standardization. "But > the language isn't complete" you cry? True, but only to a limited > degree. "But it'll stifle innovation" you say? What's more > important, innovation or code reusability? [[hey, cool down. i'm > kicking straw men here.]] I happen to agree. As a matter of fact some of us started doing things many months ago. The drift of things and the needs of the users in this respect were made quite clear at the C++ ``workshop'' in Santa Fe. The first step, a much more detailed and specific manual, has been in the works for months. This is needed independently of what further features are needed in the language. Such a manual revision does not necessarily stifel innovation. As a matter of fact I consider it essential for further growth. Unless the basic language features are well defined in a way that people can understand and agree on, further progress is irrellevant. The work of the ANSI C committee alone makes a revision necessary. The language does not yet measure up to where I think it ought to be, but given the 2.0 features (mostly described in quite some detail already) the major ``missing'' parts are parameterized types and (probably) exception handling (this too is no secret either: I have been telling people for years that this is the way I would like C++ to evolve and my views here reflect those of quite a number of users). Fortunately, these improvements can be done as compatible extensions. Much more about that at the C++ conference in Denver. And no, I am not under the illusion that I can complete such a revision of the C++ reference manual single handed, but we must avoid the multi-year delay that a formal standadization implies. I hope to produce a revised and rather extensively reviewed manual in half a year or so. That ought to give us sufficient stability for formal proceedings to take their necessary time. We don't just need time for formal proceedings, but also to gain experience as C++ programmers (as opposed to experience as C, Pascal, Modula2, Ada, etc. programmers). > C managed to live for so long without a standard because there > was a de-facto one in K&R. This is not true of C++ *because* of > Stroustrup -- he's being very flexible. Hmmm. I feel tempted to argue about that, but maybe I ought to keep out of this particular discussion. > It's time to start talking about a standards effort. Starting > the discussion today means it will be one to two years before > we have a real committee, and one to two years before we have a > standard. Figure three years from now *at best*. Starting today > is not too soon; starting today will not unreasonably stifle > the innovation that is under way and will wrap up in the next > two years. Again. I agree fully. We need work on at least three fronts: (1) Language definition and direction of extensions. (2) ``Simple'' urgent things such as header file layout, file suffixes, and the most basic libraries. (3) more ambitious libraries and programming environments. I'm trying to do something about (1) with the help of (hopefully all of) the purveyers of C++ compilers and tools and some experienced users. The purveyers of C++ compilers and tools ought to get together with some experienced users to solve (2). There are immediate problems that are amenable to immediate solutions given cooperation. I think the will is there. What we need is a time and a place; maybe we can come up with a suggestion for that at the C++ conference in Denver. (3) is too open ended to allow specific solutions. For starters, we can start looking for a good forum for such discussions at the conference in Denver. > I will now go and don my asbestos suit! :-) Really? This isn't comp.lang.c. We are usually more polite here. Thanks for bringing up a serious and really tricky problem. Hope to see you in Denver! - Bjarne -- > Steve Simmons ...!umix!itivax!vax3!scs > Industrial Technology Institute, Ann Arbor, MI. > "You can't get here from here."
scs@itivax.UUCP (Steve C. Simmons) (09/23/88)
In article <8219@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes:
:Steve C. Simmons from the Industrial Technology Institute,
:Ann Arbor writes
: > The same process has already started with C++. There are ads
: > for C++ compilers (well, one) with parameterized types, a feature
: > not (yet) in cfront or g++.
:
:Ads for a C++ with parameterized types? I haven't seen them. There has
:been much talk, a little writing, and a few experiments, but I haven't
:seen an extended C++ for sale.
Sorry, my error. I was remembering an ad for eiffel.
--
Steve Simmons ...!umix!itivax!scs
Industrial Technology Institute, Ann Arbor, MI.
"You can't get here from here."henry@utzoo.uucp (Henry Spencer) (09/23/88)
In article <6590064@hplsla.HP.COM> jima@hplsla.HP.COM ( Jim Adcock) writes: >For example, a "level 1" implementation of a C++ compiler >might only support single inheritence, a "level 2" >implementation of a C++ compiler might mean that multiple >inheritence is supported, "level 3" implementations of >the language might support parameterized classes ...... I think this is a mistake; it means that we would have several different languages rather than one standard one. (It gets still worse if you have optional pieces that aren't part of a linear sequence; there are something like 4096 different languages that are technically "ANSI standard COBOL".) Note that X3J11 made a conscious decision *not* to define multiple levels of C, for exactly this reason. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
scs@itivax.UUCP (Steve C. Simmons) (09/23/88)
In article <6590064@hplsla.HP.COM> jima@hplsla.HP.COM ( Jim Adcock) writes: >At this point in time what I'd rather see is an >agreed upon "subset" of the language that we could >expect all "C++" compilers to accept -- while still >allowing the various compiler camps to experiment >with new features that may prove to be generally >useful above and beyond this core set. That's effectively what we'd get out of a standards effort. In fact, that's what happened with C. K&R defined the first standard, then people slowly and carefully added features. Time showed which ones survived and which ones didn't. If the first standard hadn't been there, we'd have probably seen much worse fragmentation. >Alternately [or in addition to], it might be nice if the >various compiler camps could come up with agreed upon definitions >of various "levels" . . . a "level 1" implementation of a C++ compiler >might only support single inheritence, a "level 2" >implementation of a C++ compiler might mean that multiple >inheritence is supported, "level 3" . . . An interesting idea, but it's not clear if (a) there's a lot of value here or (b) how things could be broken down into heirarchies. Is multiple inheritance needed for parameterized types? Maybe better to say "here's a definition of the parameterized types extension", "here's a definition of the multiple inheritance extension", and then offer compilers with extension packages A, B, C, etc. Unfortunately I doubt that's much help for the compiler vendors. It's probably more work to develop/market/sell all the extensions separately than it is to do the whole ball of was. -- Steve Simmons ...!umix!itivax!scs Industrial Technology Institute, Ann Arbor, MI. "You can't get here from here."
eric@snark.UUCP (Eric S. Raymond) (09/23/88)
In article <6590064@hplsla.hp.com>, jima@hplsla.HP.COM (Jim Adcock) writes: > Alternately [or in addition to], it might be nice if the > various compiler camps could come up with agreed upon definitions > of various "levels" of the C++ language so that we could > know what major features of the "C++ language" are going to > be available to us when we buy a particular vendor's > compiler. Aaaargh! Back! Back! <raising silver crucifix> Some bad ideas there are that refuse to die, that rise out of unquiet graves to trouble us long after we had thought them dead and gone. This particular revenant had its gory fingers deep in the self-destruction of PL/1 and the petrification and slow death of Pascal, and even as we speak menaces the IEEE POSIX standard. Yea, I myself bore a torch and pitchfork against it the last time it threatened net.humanity; it possessed an otherwise estimable gentleman named Rahul Desi and attempted to worm its grisly way into the C standards process. Hear now the grisly tale of its depredations. In PL/1, there was this idea of 'subsetting'; the standard allowed lots of orthogonal binary choices about the semantics and implementation (or non-implementation) of various constructs and (especially) data types. The result? At first, a chaotic mess that drove strong programmers to fits of madness and their managers to despair. Later, least-common-denominator compilers that didn't support *any* of the competing options -- because it had been learned, at the cost of the Gods alone know how many man-hours, that nonportable 'features' amounted in the end to little more than a snare and a delusion even in single-vendor (IBM) environments. And for this among many other reasons, PL/1's dominion has dwindled to a ragged and remnant few. During the Pascal standardization push of the early '80s this fell creature re-manifested in a subtler and more insidious form -- as the idea of ISO Pascal 'levels' 0 and 1. Once again evil bestrode the earth; no attempt was made to exorcise ISO-incompatible versions of the 'Level 1' features, so portability was never obtained for the semantics ISO had blessed. After a time, all the old limitations of Level 0 became once again the lot of weary programmers. And all know how Pascal has since been brought low from its once-mighty repute, reduced indeed to a toy for weekend PC hackers. Even as we speak, the necromancy of lazy vendors has once again conjured this fearsome lich into the demesne of the IEEE P1006.1 committee. A righteous few persevere in opposing it, crying "One standard! No options! No crippling!". It is by no means certain that they will prevail; and if they do not, POSIX will surely become but a twisted and shrunken grotesque of what it might have been. Therefore: as you value your very soul, call not upon the "levels and subsets" monster, but seek to slay it with all the strength of your wit. Let's kill it *dead* dead this time, huh guys? -- Eric S. Raymond (the mad mastermind of TMN-Netnews) UUCP: ...!{uunet,att,rutgers}!snark!eric = eric@snark.UUCP Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
bs@alice.UUCP (Bjarne Stroustrup) (09/23/88)
I think that having several ``levels'' of C++ language features is a truly bad idea. Essentially, all the features added to C++ since the book or under consideration (e.g. multiple inheritance, parameterized types, and exception handling) are there to help build better and more general libraries. For economic reasons library providers would feel oblidged to produce libraries for the lowest level of the language (to reach the greatest number of users) and such library interfaces would have to be expressed in the lowest ``level'' features. This would be a great disservice to all users, not least the novice and casual users. We already have this problem because you could consider C as ``level -2 C++'' so there is a great insentive to provide libraries that are common to C and C++. This implies that no classes, no overloaded functions, etc. may appear in the interfaces to those libraries. Yuck! Alternatively, there can be different interfaces from C and C++ but even this can seriously compromise the elegance of the C++ interface and bias the design and programming style. We will also get the problem repeatedly as we ramp up to the total set of facilities from the set available now. However, I think this will be manageable.
johnl@ima.ima.isc.com (John R. Levine) (09/25/88)
In article <dzj2T#X460J=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: > [ standards that define subsets are a hellish abomination] Before we put this issue to sleep, I feel compelled to point out that there are two ANSI standards that have sucessfully defined subset languages. Perhaps coincidentally, they are also the two oldest and most successful languages, Fortran and Cobol. The F77 standard is nicely laid out so that on each facing pair of pages, the right page defines the full language and the left page defines the subset language. There used to be quite a few subset implementations back when 64K was a serious amount of memory for a minicomputer, though now everybody goes for the full language. The Cobol standard defines modules at different levels, and you see reports that a compiler has the full language at level 2 with the file handling module at level 4, and so forth. In both cases, the standard gave considerable thought to existing practice, e.g. subset F77 is more or less the part of F77 that was already in F66, so that there is little incentive to misimplement stuff in the interest of making old code work. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { bbn | think | decvax | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw
jima@hplsla.HP.COM ( Jim Adcock) (09/28/88)
I think the point I was trying to make is that C++ compiler vendors ARE providing compilers with various "levels" of functionality. I see this as likely to continue as long as bs and "everyone else" continues to work on the language trying to figure out exactly what it should contain. It is "nice" to fantasize that all of a sudden we're going to have an emaculate conception and a finalized version of C++ is going to pop out whole and flawless -- but I for one do not see this as happening. The alternative is to try to agree upon standardized "subsets" so at least the customer knows what their buying. This would actually put pressure on vendors to provide compilers with the latest and greatest "agreed upon" features since who wants to provide a product with reduced functionality? As it now stands anyone can pretty much call anything they make a "C++ compiler" and then there are endless discussions about whether a certain library is going to compile under a given compiler. I believe that some intermediate "subset" standards, where the various compiler vendors get together and agree on what they agree upon, and agree to disagree on areas where the language is still developing, would be preferable to waiting for the indefinite future for the "whole language" to magically appear. As a practical matter I believe that the "subset" standards that can be agreed upon, and the levels of complexity that various vendors' compilers are likely to support break down as follows: 1) single inheritence. 2) multiple inheritence. 3) parameterized classes. 4) ??? Probably most compilers being offered are at about level #1, with level #2 in the works. Why not make a bow to reality and the needs of customers to know what they are buying, and "formalize" these admittedly intermediate levels of conformance? Isn't partial agreement to standards better for customers than no agreement at all? Also: EVERY compiler presently being bought by customers implements a SUBSET of the C++ language. And EVERY library being offered by library writers is written using a SUBSET of the C++ language. Why rail against reality? The reality is everyone today IS using subsets of the C++ language. Why not agree to standards on those subsets, so that at least there are only N subsets, rather than N-factorial !!!!???? At my location the non-standardization among C++ vendors IS forcing me to work with the level -2 subset of the C++ language -- IE "C". How about getting some standards set so I can at least work at the -1 or -0 subset level of the C++ language???
henry@utzoo.uucp (Henry Spencer) (09/29/88)
In practice, in the absence of formal standards processes (e.g. ANSI), de-facto standards tend to be set by whatever documents are available. At present, we essentially have two levels of standard for the language itself: Bjarne's book, and his paper in the C++ Workshop proceedings (which includes multiple inheritance and a number of other things). The formal reference manual he now has in the works will probably supersede the latter in the public eye. Most every supplier will be trying to bring his product up from book level to paper level, but they've had less than a year to do that so far. I really don't see any grievous need for multiple levels of standard, certainly nothing sufficient to justify the grievous hassles that would result. There will *always* be inadequate implementations, but I do not see that we have any reason to legitimize them. The *lowest* level of quasi-official standard is, in fact, the real standard; let's set that at the level we really want, not at the lowest level we think we could put up with. Actually, our big problem at the moment is libraries, not the language proper. It's hardly surprising that libraries vary widely, when figuring out what to put in them requires gathering a diverse set of papers, Bell Labs tech reports, Usenet postings, etc., and trying to make sense of it all. We badly need a *single* readily-available document that describes a basic set of libraries in considerable detail. -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mike@ai.etl.army.mil (Mike McDonnell) (10/03/88)
In article <1988Sep29.164824.25390@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In practice, in the absence of formal standards processes (e.g. ANSI), >de-facto standards tend to be set by whatever documents are available. >At present, we essentially have two levels of standard for the language >itself: Bjarne's book, and his paper in the C++ Workshop proceedings >(which includes multiple inheritance and a number of other things). The >formal reference manual he now has in the works will probably supersede >the latter in the public eye. Implementations can define standards as well as documentation can. GNU's "g++" has some good ideas that differ from Stroustrup's book. In particular, they have modified the language slightly to allow a LALR(1) grammar rather than the infinite-lookahead required by "the book". This allows better optimization and more "modern" compiler techology, or so they say. There are lesser differences as well; as documented with the distribution. These ideas should be considered. Here is the relevant part of the g++ documentation, complete with a characteristic Stallman diatribe: * The design of the C++ programming language did not take into account the usefulness of being able to specify that language using an LALR(1) grammar. As a result, in order to correctly parse it, one needs a look-ahead lexical analyzer (with infinite lookahead), and a recursive descent parser, guided by some good heuristics. This approach was not taken in GNU C++, because it is considered archaic, notoriously difficult to extend syntactically, and generally offensive. GNU C++ uses an LALR(1) grammar so that users can easily understand, and readily modify the compiler to suit their needs. Free software is useless if it becomes captive to an inaccessible or undesirable technology. However, in providing such a grammar, some syntactic forms were lost, most notably old-style C function declarations and occasionally function parameters which are declared longhand to be pointers to functions are not recognized properly. -- Mike McDonnell at the U.S. Army Engineer Topographic Laboratories, Bldg. 2592 Fort Belvoir, VA 22060-5546 TEL:(202)355-2724 ARPA: mike@ai.etl.army.mil