From -8059297871785602554 X-Google-Thread: f78e5,ccf6a146f69dd0fc X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.maxwell.syr.edu!feed.news.tiscali.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: pjp@dinkumware.com ("P.J. Plauger") Newsgroups: comp.std.c++ Subject: Re: Legacy issues:was:Re: standardizing the exception handling mechanism across platform/compilers Date: Tue, 23 Aug 2005 02:21:46 GMT Lines: 124 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1123763925.850895.253360@f14g2000cwb.googlegroups.com> <42feece5$0$16078$892e7fe2@authen.white.readfreenews.net> <430202d3$0$83690$892e7fe2@authen.white.readfreenews.net> <7NpMe.1913$r54.162@newssvr19.news.prodigy.com> <1124226617.637407.216790@g49g2000cwa.googlegroups.com> <9vednf6yF4qWi5reRVn-hA@giganews.com> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1124763713 14618 158.152.254.254 (23 Aug 2005 02:21:53 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 23 Aug 2005 02:21:53 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Priority: 3 X-RFC2646: Format=Flowed; Original X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-MSMail-Priority: Normal X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j7N2Lk7u014803; Tue, 23 Aug 2005 12:21:46 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Mon, 22 Aug 2005 06:36:09 -0500 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.20 X-Postfilter: 1.3.32 X-Authentication-Warning: serv2.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1899 ""Steven T. Hatton"" wrote in message news:CI-dnYbCl5arsZTeRVn-sA@speakeasy.net... > P.J. Plauger wrote: > >> ""Steven T. Hatton"" wrote in message >> news:hvSdncsz9YoE9pveRVn-jQ@speakeasy.net... >> >>> 1) _Are_ we going to break a zillion loc? >> >> No. > > It may be worth clarifying what it means to "break" existing code. This > can > be more subtle than it seems. For example, the naive understanding would > suggest it simply means that old code will not work with the > (hypothetical) > new standard. That might be dismissed by saying that people who have such > non-conforming code could simply compile it with a compiler that conforms > to the older language specification, and link to the resulting object code > when building newer versions their program. > > One problem with that line of reasoning is that it fails to take into > account that object code produced by one version of a compiler may not be > compatable with that produced by another version of the compiler (or a > completely different compiler, for that matter). That means the compiler > implementors would need to provide multiple 'flavors' of C++ > compatability. > Though that is already done, to some extent, it is probably not the kind > of > burdon that should knowingly be placed on the implementor. (IIRC this was > Walter Bright's objection.) If a compiler cannot both conform to a revised C++ Standard and support a large base of existing code, the owner of the latter will disdain the former. Nothing subtle about that. Happens all the time. > OTOH, the current Standard breaks a lot of code when implemented > correctly. > I've seen this with GCC. Often the more correctly conformming compiler > with refuse to compile code that successfully compiled under and older > version. There was no prior C++ Standard to "break" in 1998. The C++ committee deliberately took advantage of this one-time latitude to make any number of changes to C++ as we knew it circa 1989 (when standardization began), which was itself pretty much an experiment in progress. You can't get away with that twice. > I've also seen occasions where other languages, or development kits, have > made rather abrupt breaks with the previous versions. We see evidence of > this when we encounter older Java applets, and try to use them with the > newer Java implementations. Of course such breaks with the past should > weigh the cost against the returns. It's easier to do when the product is > new and the user base is limited. Right. And it helps when there's no international standard involved. > I have the sense that C compatability could become more problematic as C > continues to evolve. Which C should C++ be a (an approximate) supperset > of? That's well specified in the C++ Standard. Both the C and C++ committees have made progress, in recent years, on reconciling the differences that arose in the 1990s. > There is also a possibility of providing configurable behavior. An > example > might be some means of providing multiple definitions of functions of type > unexpected_handler. There would thus be multiple "standard" ways of > handling unexpected exceptions. One of the definitions might "break" > existing code, whereas another may be compatable with such code. That, in fact, is what implementers have to do when a market exists for multiple dialects of a language. >>> 2) So? >> >> If the committee tries to do so, the revised standard will be >> ignored by a significant portion of their constituency. > > The entire standard, or just a particular feature? Ah, there's the rub. Once the community decides that 100 per cent conformance is undesirable, then the community splinters into groups each with its own list of deviations. Thus, the presence of even one contentious feature dramatically weakens the effect of the entire standard. Look what's happend because of export -- nobody even discusses all the other ways that compiler and library vendors choose not to conform. > Either way, it is > certainly not an ideal situation. Ideally there will be support for both > existing code, and new features, and a reasonable transition path from use > of the existing features to use of the "new and improved" features. But now you're talking about multiple dialects, and transition plans, and other things that are both expensive and outside the pale of standardization. > My impression of C++ usage is that some good ideas have not gained > popularity due to the inertia of existing practices. One example is the > use of error return values as opposed to the use of exceptions. IMO, > there > is rarely a situation in which retruing an error value is superior to the > use of exceptions. Nonetheless, when existing code uses error return > values (or worse, global error flags), it is difficult to introduce > exception handling in an elegant way. And the C++ Standard has next to nothing to say about this sort of thing. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]