From -9166151275753564222 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,9a6b7da9ba54eaea X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-08-10 08:57:27 PST Newsgroups: comp.std.c++ Path: gmd.de!xlink.net!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!swrinde!menudo.uh.edu!uuneo!sugar!daniels From: daniels@NeoSoft.com (Brad Daniels) Subject: Re: C++ Language Extensions Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Tue, 10 Aug 1993 13:40:10 GMT Message-ID: References: <1993Aug10.060148.27191@ucc.su.OZ.AU> Lines: 49 In article solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes: >maxtal@physics.su.OZ.AU (John Max Skaller) writes: > >>In article solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes: > >>>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. > >> The ISO process does not work like that. There is a Standard, >>it stands for a while, then lapses or gets renewed. There is no provision >>for continuous upgrades or additions, other than a creation of a new >>ISO work item. > >I may not have made myself clear, or I may not completely understand the >current C++ standardization effort. I was under the impression that >the C++ standard will include EH, etc. as an integral part of the standard >(rather like the Ada "no extensions, no subsets" policy). I was not advocating >evolution of standards, but rather splitting the standard into multiple >"work units": "Core C++ Language", "Standard C++ Extension for Exception >Handling", etc. Perhaps the mention of "status" in the first sentence quoted >above was misleading. I was refering to the process by which a proposal >*becomes* a standard. An extension would not be a "standard" until it was >"frozen". Perhaps the old ISO terms DP, DIS, and IS would make this clearer. >I believe the term "addendum" is also relevant here. Despite the potential nuisance as far as determining standards conformance, I like this idea. There is certainly precedent for this kind of approach, e.g. in the POSIX 1003.x standards and various ISO-9000 levels. Any head- aches in maintaining a set of standard extensions should be less than the headaches of trying to decide whether to include the extensions in a monolithic standard. Later standards efforts could then choose whether to let extension standards lapse or to fold them into the base language standard. Extension standards would also help reduce the need for revisions to the base standard except for clarification purposes, thus potentially improving the quality of all part of the standard by reducing the number of issues the com- mitte needs to address at any given time. - Brad -- Brad Daniels | "Let others praise ancient times. daniels@neosoft.com | I am glad I was born in these." I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D) don't speak for my employer. |