From -5334478654525772192 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e445fe05b100a0aa X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-08-10 04:45:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!212.74.64.35!colt.net!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: Daniel Miller Newsgroups: comp.std.c++ Subject: Re: C++ exception handling Date: Sat, 10 Aug 2002 11:44:22 GMT Organization: Tellabs Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3D53F0DA.5020801@tellabs.com> References: <20020802141846.59203.qmail@web9902.mail.yahoo.com> <_2S29.267$a01.33863850@newssvr13.news.prodigy.com> <3D501B4D.BE8FB29@web.de> X-Trace: mail2news.demon.co.uk 1028979867 mail2news:25431 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au 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++@mdir.ucar.edu User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en,lt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Fri, 09 Aug 2002 11:42:32 CDT Lines: 143 Xref: archiver1.google.com comp.std.c++:13198 Daniel James wrote: > In article <3D501B4D.BE8FB29@web.de>, Alexander Terekhov wrote: > >>>If we ditch the stupid runtime checks... >>> >>Do really think that runtime checks without unwinding would be >>stupid? >> >>Why? >> > > I shouldn't have said "Stupid", I don't believe they offer any > benefit - or rather that they offer less benefit than an a purely > comiple-time exception checking mechanism would, and have an > unacceptable cost. The consensus seems to be that the exception > specification mechanism we have in the language today isn't worth > using (the advice from most C++ language authorities is to avoid > ESs apart from empty ones) > > If checks were made at compile-time there should be no need to > perform any additional checks at runtime. Runtime checks are bad > because they have a cost in code size and in execution time, > compile-time checks are good because they eliminate the need for > runtime checks. [...snip...] > As I said in my previous post, I do appreciate that getting > compile-time ES checking right isn't going to be easy. There are > issues with templates, and with pointers to functions, and whether > a function's ES should be part of it's type (I think yes, but that > raises new issues). I think the first thing the community has to > do is to accept that what we have today isn't really useful - and > isn't being used, because of that - and to change it. No, that is not the "first thing" that someone needs to do. With your "first thing" you are assuming that "the community" is open-mindedly liberal in their thinking, entertaining all new ideas no matter how silly to see if there exists any 5% pearl of wisdom to harvest out of the 95% dreck of the idea. Instead I consistently see over & over that "the community" behaves largely in the opposite manner. Even if an idea is 95% perfect, "the community" will tear the idea to shreds, focusing on the 5% of tarnish, and then dismiss the entire idea in order to preserve the status quo (instead of polishing off the 5% of tarnish or mounting the missing crowning jewel). And maybe this defense of the status quo is natural human behavior when pride-of-authorship (e.g., of C++98) is involved or when they themselves have not yet invented a solution to the problem. Given this frequently-exhibited proclivity toward treating all new ideas as deserving of attack as a mechanism of enforcing the status quo, don't play into that game, due to its squelching effect. Instead let us focus *not* on 1) changing people's minds, 2) then reaching consensus, and then 3) then taking action together as a united happy agreeing front, but rather on the opposite order: 1) take action yourself (and any few direct allies with whom you share common viewpoints) where this action is building a working demonstration. But make sure during this phase that you push for something extremely worthwhile for the future of humankind with very few (or no) warts because this is the phase of free thinking, open-mindedness, friendship, invention, discovery, and excitement. If you don't get it right during this phase, the idea will forever be crippled, as the cement sets in the next phases. 2) then build consensus by making it part of the public distribution of one or more compilers. This naturally involves freezing the idea to some degree so that churn is minimized as it is publicly rolled out in this wide distribution. 3) then let the good experience gained by the ever-more-widely-distributed publicly-released products change people's minds, and 4) then standardization submissively complies with widely-established existing practice, at most tinkering around the fringes---as it should be. During this phase, adjust the documentation from prior phases so that it conforms to the standard-body's own variation of standards-speak. Specifically regarding compile-time enforcement of exception-specifications, devise a solution to those big problems yourself (or among your friends). Write it up as formally & lucidly & completely as possible, such as John Nagle's http://www.animats.com/papers/languages/index.html (or in a different era, such as Musser & Stepanov's Ada generics library and precursors of STL which attracted Stroustrup's interest). Modify a compiler for which you have source code. Preferably modify an open-source compiler which is willing to consider contributions from outside their regular developers (unless you are one of those regular developers). Currently this set of open-source C++ compilers willing to entertain extensions might include GNU C++, but in the future might include OpenWatcom as well. Design your extension not as a hack which barely works in a few rigged-up cases, but rather as production-quality which can be turned on via a command-line option (where the extension is off by default). Try out the extension extensively. Learn about it among your friends & colleagues. Improve the idea before throwing the idea out to "the community" meat-grinder. Negotiate to get the extension placed into the production compiler product to ship at next release (so that we all may try out the extension). Continue evolving that write-up to mesh well with the standardese language of ISO/IEC 14882. Negotiate with other compiler vendors over time to add the extension, as we see with compiler vendors implementing Microsoft & GNU extensions prior to standardization. Don't get me wrong, though. The meat-grinder of seemingly limitless negativity in "the community" is very useful criticism, especially when observing the meat-grinder shred someone else's ideas which are vaguely similar to your own, allowing you to hone in on what went wrong in the other person's ideas and to adjust your ideas in private to no longer be susceptible to that criticism. Harvest the pearls of wisdom which come your way via that process (and throw away the dreck). It is my hope that no rational human being in the C++ community is permanently fervently against *all* future *perfect-without-flaw* variations of exception-specifications, but rather today there are numerous people who are against exception-specifications as exception-specifications currently stand due to the not-yet-completely-thought-out topics. If you or others truly solve the various template problems, pointer-to-function problems, and span-compilation-unit problems (the easiest of the three IMO) and then follow the plan laid out above, as a matter of course minds will in fact change and the feature would eventually be accepted (and maybe even celebrated as a major achievement). The worst that happens by trying to solve those big problems with exception-specifications is that you discover (and preferably formally prove) why they cannot be solved, which is its own kind of advance of humankind to no longer lament lack of progress on that topic anymore. By the way, I fully agree with every bit of your advocacy of exception-specifications. If there exists a reason why I myself don't take up the challenge regarding exception-specifications, it is that I have been focusing on other hard topics in C++. Go forth and prosper. :-) --- [ 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 ]