Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!ukma!rutgers!bellcore!faline!thumper!ulysses!andante!alice!bs From: bs@alice.UUCP (Bjarne Stroustrup) Newsgroups: comp.lang.c++ Subject: Re: Standards For C++ Keywords: standards growthrate Message-ID: <8219@alice.UUCP> Date: 20 Sep 88 01:40:59 GMT References: <255@itivax.UUCP> Distribution: na Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 135 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."