From -824162394816218942 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,9a6b7da9ba54eaea X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-08-09 04:46:49 PST Path: gmd.de!xlink.net!sol.ctr.columbia.edu!usc!cs.utexas.edu!rutgers!uwvax!gjetost.cs.wisc.edu!solomon From: solomon@gjetost.cs.wisc.edu (Marvin Solomon) Newsgroups: comp.std.c++ Subject: Re: C++ Language Extensions Message-ID: Date: 9 Aug 93 10:45:57 GMT References: Sender: news@cs.wisc.edu (The News) Organization: U of Wisconsin Madison - Computer Sciences Lines: 66 When I first saw the phrase "standard extensions" I thought it meant "standardized extensions" rather than "extensions to the standard". After reading all the flaming on this group, it still seems to me that the former interpretation would have been preferable. What I'm suggesting is something like this: "EH [or RTTI, NS, etc.] is an extention. A conforming compiler need not implement it. However, a compiler that claims to implement 'standard EH' should do so as follows: ...". In other words, standardize both the "core" lanaguage and extensions, but clearly indicate which is which. Each conforming compiler should come with a list of extensions it purports to support. It could even have a switch turn the extension on and off (to support pre-extension code and to aid in portability testing). It would only be practical to apply this approach to relatively "separable" and upward-compatible extensions. An "extension" that caused substantial changes to the unextended part of the language would lead to large headaches in maintaining multiple versions of tools. However, the kinds of things that have been mentioned as extensions generally affect the core only in usurping a couple of reserved words. The advantage to this approach is that it could substantially speed the standardization process. For the core standard, concentrate on cleaning up ambiguities in the ARM. If ANSI could get a core standard (or even a draft core standard) out quickly, compiler vendors could concentrate on making sure their products conform and application programmers with a strong portability requirement could work on confining their code to the core. (Such users probably avoid anything that smacks of "extension" anyhow). A standard is a useful tool to adjudicate disputes: When a program behaves differently on different compilers, the consumer knows whom to blame. It also server as a bit of insurance for conscientious compiler writers (if they adhere carefully to the standard, there is less likelihood that they will be forced to make expensive changes to their compilers) and conscientious application writers (their code is more likely to be portable). Finally, it helps to foster a market for standards-conformance-testing tools. Standard extensions provide many of the same benifits. They encourage vendors to differentiate themselves by offering extensions ("The Acme compiler supports ANSI standard exceptions") without the danger of isolating themselves (Nobody uses the Acme compiler because it doesn't support the style of exceptions implemented by Best Corp, which has emerged as the industry leader). Standard extension can be introduced later than the core standard. The extension process should be an on-going activity: Someone suggests the need for a new extension (e.g., in this news group). After some discussion, a specification is proposed. One or two vendors create experimental implementations. Based on their experiences, the spec is revised and issued as a draft standard. More vendors implement the proposal and offer it to selected customers. Experience leads to further refinements, and the standard is revised and "frozen". Emboldened by the existence of a standard, and driven by market pressure, many more vendors choose to offer the extension. Eventually, the feature becomes so popular that no serious vendor would consider offering a compiler that doesn't support the "extension". Thus at any time each extension would have its own status: Proposed, draft, or frozen. The benefits of a standard for the core language would not be delayed by waiting for the various extensions to settle down. This approach would also expedite the generation of extensions. Because publication of an extension standard would not "obsolete" existing compilers (and programs), there would be less pressure to prove the importance of an extension before adopting a standard for it. Once the extension is standardized, the marketplace can decide whether it is worthwhile. -- Marvin Solomon Professor and Chair Computer Sciences Department University of Wisconsin