From -3708079434896129357 X-Google-Thread: f78e5,ccf6a146f69dd0fc X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news4.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: kuyper@wizard.net Newsgroups: comp.std.c++ Subject: Re: Legacy issues:was:Re: standardizing the exception handling mechanism across platform/compilers Date: 24 Aug 2005 05:40:02 GMT Organization: http://groups.google.com Lines: 58 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1124809777.549822.9630@f14g2000cwb.googlegroups.com> 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> <1124718740.660393.208780@o13g2000cwo.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Delivered-To: std-c++@ucar.edu X-Trace: posting.google.com 1124809782 25377 127.0.0.1 (23 Aug 2005 15:09:42 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 23 Aug 2005 15:09:42 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=65.242.71.114; posting-account=bPBxkgwAAABzUwlEAMy-xGlLqZFJ5Jz_ X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox7.ucsd.edu; Tue, 23 August 2005 08:09:44 -0700 (PDT) X-Spamscanner: mailbox7.ucsd.edu (v1.6 Aug 4 2005 15:27:38, -2.6/5.0 3.0.4) X-MailScanner: PASSED (v1.2.8 13727 j7NF9hLg030107 mailbox7.ucsd.edu) X-Virus-Scanned: amavisd-new at ucar.edu X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.ucar.edu id j7NF9vNC005177 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:1912 ravinderthakur@gmail.com wrote: > hi all, > > first of all a big apology for not being able to keep myself in sync > with my posting. i was a bit involved in fixing some impossible to find > bugs in some software  > > > now back onto my original posting a few clarifications are in order: > > > what i was suggesting was to standardize in some way the runtime > behavior or c++ exceptions rather than the compile time behavior of > c++. to see the motivation for the same lets see how a large part of > the software development occurs: > > most of the applications being developed try to reuse the existing code > and the ways of > reuse is either at the source code level or to use the code at the > binary level (aka the library file approach.). > > one the end of the library vendor, he cannot throw exceptions from the > functions exposed in the library files because the runtime model of the > exceptions is not standarized across the compilers/platforms. > > eg. given below is the link to some of the issues forbidding the use of > exception from real world experience: > http://www.mactech.com/articles/mactech/Vol.15/15.01/C++ExceptionsMacOSCode/ There's no gurantee that you can link code compiled with one compiler to code compiled with another compiler, or even the same compiler if different command line options are concerned. Exception handling is just one special case of how this problem can be manifest. Argument passing conventions, conventions for returning function values, name-mangling schemes, and just the most basic things that can cause incompatibilities. There can be differences in the size, representation, and alignment of fundamental types, differences in the padding between members of a struct, and differences in how bit fields are implemented. Even in C, it is possible and commonplace for an implementation to inline some or all of the implementation of one of the standard library functions, so different compilers can use different and imcompatible standard libraries. This is even more true in C++, where the part of the standard library that wasn't inherited from C are often implmented entirely in the standard headers. The solution isn't a change to the C++ standard to specify those details. Those details are properly platform-specific, and the solution should be platform specific. It's up the vendors developing for each platform to agree on and conform to platform specific conventions for all of these issues. That has, in fact, happened in many cases. --- [ 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 ]