From 6606840430422954805 X-Google-Thread: f78e5,ccf6a146f69dd0fc X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!proxad.net!skynet.be!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: hattons@globalsymmetry.com ("Steven T. Hatton") Newsgroups: comp.std.c++ Subject: Re: Legacy issues:was:Re: standardizing the exception handling mechanism across platform/compilers Date: Mon, 22 Aug 2005 06:30:22 GMT Lines: 77 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.demon.co.uk 1124692241 25666 158.152.254.254 (22 Aug 2005 06:30:41 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 22 Aug 2005 06:30:41 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: KNode/0.9.2 X-DMCA-Complaints-To: abuse@speakeasy.net X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox8.ucsd.edu; Sun, 21 August 2005 18:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU 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 j7M6UMEL010611; Mon, 22 Aug 2005 16:30:22 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Sun, 21 Aug 2005 20:36:53 -0500 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.21 X-Spamscanner: mailbox8.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 0.0/5.0 3.0.4) X-Postfilter: 1.3.32 X-Authentication-Warning: serv1.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 67487 j7M1b0is068580 mailbox8.ucsd.edu) Xref: g2news1.google.com comp.std.c++:1891 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.) 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. 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. 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? 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. >> 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? 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. 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. -- NOUN:1. Money or property bequeathed to another by will. 2. Something handed down from an ancestor or a predecessor or from the past: a legacy of religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF, from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/ --- [ 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 ]