From 1826402402811700270 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,6d43dabd81d37c8e X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-01-24 18:30:19 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: philippe_mori@hotmail.com ("Philippe Mori") Newsgroups: comp.std.c++ Subject: Re: suggestions: about constructors and destructors Date: Sat, 25 Jan 2003 02:30:14 +0000 (UTC) Organization: Bell Sympatico Lines: 60 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <23478c42.0301230926.39a6959c@posting.google.com> <7f2735a5.0301241511.20024ed6@posting.google.com> X-Trace: mail2news.demon.co.uk 1043461814 6108 10.0.0.1 (25 Jan 2003 02:30:14 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 25 Jan 2003 02:30:14 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18cG5E-0001aN-00 for mail2news@news.news.demon.net; Sat, 25 Jan 2003 02:30:12 +0000 X-Received: by mulga.cs.mu.OZ.AU id NAA27944; Sat, 25 Jan 2003 13:30:08 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-NNTP-Posting-Date: Fri, 24 Jan 2003 18:51:52 EST X-Spam-Status: No, hits=-3.9 required=5.0 tests=FORGED_HOTMAIL_RCVD,INVALID_MSGID,NOSPAM_INC, PRIORITY_NO_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_05_08 version=2.41 Xref: archiver1.google.com comp.std.c++:17508 > > In your example, it looks like you aren't actually using the int. > You just want the destructor to have a different "signature", > so that you can't destroy the "Contained" object normally. > void foo() { > Contained c; // Would be illegal, 'cause you can't destroy it. > Contained *d = new Contained; // Legal > delete d; // Not legal ("default destructor") > delete(1) d; // Legal > } > Is this what you had in mind? > > If so, I can offer an alternative: > struct Contained { > private: > ~Contained() {} // Private destructor > public: > // When other routines want to destroy it, they call destroy > void destroy() { // or void destroy(int) if you like > delete this; // Calls private destructor > } > }; > > Conventional wisdom is: An object ought to know it's own state. Once > you destroy it, there is no more state. Therefore, there's no reason > to pass arguments to the destructor. > This is also what I think... If you need diffrent destruction policies, then make different classes for each cases (provided that the argument only serve to select proper destructor). This could be a template class with a specialization for the destructor... class Base { }; // No destruction class Der1 : public Base { ~Der1() {} }; class Der2 : public Base { ~Der2() {} }; and uses the appropriate class in special situation. Or you may have a Base that do not do any destruction, a derived class that does standard destruction and a member function (of Base) for your custiom destruction. When you want custom destruction, you uses Base class object and call explicitly the destruction function. Otherwise, in general case, you uses the derived class. Another alternatif is to have a flag in the base class that indicate if standard destruction should be done. The flag would be true. But if you call your custom function, you set the flag top false and do nothing in the destructor. I do not think that it worth a language changes... particulary that we should not have such design in general. And for an exception, special code is an alternative... --- [ 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 ]