From 5249941211032011349 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,4441c5f6d7843223 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-08-16 12:44:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: "Adam H. Peterson" Newsgroups: comp.std.c++ Subject: Re: C++0x Wish List (explicit class) Date: Fri, 16 Aug 2002 19:43:10 GMT Organization: Brigham Young University Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <3D48C729.40503@spamnot.codeweavers.com> <8c8b368d.0208060921.43e9e9d5@posting.google.com> <3D589892.3050008@spamnot.codeweavers.com> <8c8b368d.0208150528.2bc34601@posting.google.com> X-Trace: mail2news.demon.co.uk 1029526994 mail2news:7025 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++@ncar.ucar.edu MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-Priority: 3 X-MSMail-priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MailScanner: Passed Lines: 60 Xref: archiver1.google.com comp.std.c++:13283 > Speaking of dtors, I would also point out that boost::noncopyable has > a non-virtual dtor, which is pretty unusual for a class intended as a > base class. > > Now, I know that the usual idiom is to use private derivation so that > no reference or pointer to a class derived from boost::noncopyable > will be automatically converted to a reference or pointer to its base > class, but there is nothing to enforce this. It's just a convention. > If somehow, somewhere, someone does delete an object of a class > derived from boost::noncopyable using a pointer to its base class, the > correct dtor will not be used, and problems are likely. > > Of course, this could easily be fixed by adding a virtual dtor, but I > would presume the reason it was left non-virtual in the first place is > to allow the "empty base class" optimization, which a vtable would > prevent. Oops! Maybe this solution isn't quite as perfect as we > might assume. C++ provides any number of ways to shoot yourself in the foot if you explicitly try to. I'm all for trying to prevent common errors that might arise during a normal development cycle, but my brain is doing acrobatics to try to determine how a scenario would reasonably play out when, 1) someone derives publicly from noncopyable, and assuming that, 2) any moron would try to use it as an interface. I don't see the point of protecting a programmer from something that wouldn't occur to just about anyone actually trying to solve a problem to do. > > So tell me again how boost::noncopyable is better than extending the > use of an existing keyword in a sensible way? Okay, here it is again. (I'm talking here about making boost::noncopyable part of the standard library vs. changing the language to add explicit class.) 1) We already know it works, and how it works, as we have a proof of concept in boost. Furthermore, the things in boost's library are already on a track towards standardization and have a better chance of actually making it into the next version of the language. 2) It can in most cases be implemented by changing the standard library alone, so we don't have to make sure we haven't broken the compiler after changing the grammar since we probably don't need to change the compiler. 3) It doesn't involve overloading a keyword, introducing possible confusion to a newcomer to the language. 4) It introduces one of the uses of private inheritance, so newcomers to the language observing this may learn how to use it more effectively. (Note that it doesn't have to be explained this way. But an astute learner may simply observe this.) 5) It doesn't introduce yet another way to do something that programmers are already doing a different way, making skills more portable from one coding style to another, and preventing the invariable holy wars about how to suppress these automatic members. --- [ 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 ]