From -1449291346031704958 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,6d43dabd81d37c8e X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-01-24 15:13:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: allan_w@my-dejanews.com (Allan W) Newsgroups: comp.std.c++ Subject: Re: suggestions: about constructors and destructors Date: Fri, 24 Jan 2003 23:13:42 +0000 (UTC) Organization: http://groups.google.com/ Lines: 160 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <7f2735a5.0301241511.20024ed6@posting.google.com> References: <23478c42.0301230926.39a6959c@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1043450022 4181 10.0.0.1 (24 Jan 2003 23:13:42 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 24 Jan 2003 23:13:42 +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 18cD12-00015I-00 for mail2news@news.news.demon.net; Fri, 24 Jan 2003 23:13:40 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id KAA00939; Sat, 25 Jan 2003 10:13:36 +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-NNTP-Posting-Date: 24 Jan 2003 23:11:25 GMT X-MailScanner: PASSED (v1.2.7 42243 h0ONBPwn058028 mailbox2.ucsd.edu) X-Spam-Status: No, hits=-9.7 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Xref: archiver1.google.com comp.std.c++:17497 danielgutson@hotmail.com (danielgutson@hotmail.com) wrote > Newgroupers: ?? > Please let me know comments about the following issues. > > - overloading non-default destructors and destruction lists. > > * consecuences: > 1) when defined, non-default destr. hides the default > destructor, unless it is explicited (in the same sense the non-default > constructor does) > 2) non-default destructor only calleable through delete operator > and/or destruction list (for contained classes) > * example1: > > struct Contained > { > ~Contained(int); > }; > > struct Container > { > Contained c; > > ~Container() > : ~c(1) //only way > {} > }; 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. There is such a thing as "placement delete," which (if I understand correctly) is used only when a "placement new" expression fails in the constructor. Note that operator delete is different than the destructor, which (as far as I know) never currently gets parameters. > * example2: > struct S { ~S(int); }; > > void f(void) > { > S s; // invalid: no default destructor available > S* p = new S; > delete p(1); //ok > } Same, except you'd use p.destroy(1) at the end instead of delete p(1). Besides -- what happens if S defines operator()? Your statement above would call operator(), and delete whatever it returns... > - 'const' constructor/destructor overloading: > -> Provide the differentiation between constructing/destruction a > const and non const objects, using the 'const' keyword as a prefix of > the constructor declaration I don't understand the point of this one. > struct C > { > const C() { ... }; > C() { ... }; > }; If this WAS legal C++, the const keyword ought to come after. struct C { C() const { ... } // I want to KNOW I'm a const object C() { ... } // I'm NOT a const object }; To be consistent with the notation for const functions. > void f() > { > const C c1; //invokes C::const C(); > C c2; // invokes C::C() > } Still don't understand the motivation for this. > - non-default constructors for arrays: > { A(int); }; > > void f(void) > { > A a[10](1); > A b[10][20](2); > } > > Same applicable through the new operator (I'm not talking about > overloading the 'new'). To construct an array of objects with the same initializer. I guess this makes sense, though we've all gotten pretty good at structuring our code so this isn't necessary -- it would still be convenient. Your syntax is reasonable, too. > Suggestion: a keyword for sending the 'index value' in a parameter > of the constructor. Let's sat constr_index, where Dim denotes > the dimension number. Dim should be a constant expression. > Example using struct A (defined above) > > void g(void) > { > A a[10](constr_index<0>); > A b[10][20](constr_index<0>+constr_index<1>); > } > > will construct: > a: an array of 10 A's, receiving the consecuent index number in > the constructor. > b: a 10x20 matrix, accepting the sum of the row and the column in > the constructor. And this I don't get at all. Seems like an elaborate mechanism that would only be appropriate when the constructor takes a single int parameter. I'd rather see operator new[] accept a functor. struct Customer { //... Customer(std::string custname); //... }; std::string getname(); // Gets customer names from database Customer custlist[25](getname); Even then, it would only work when the Customer object has a single parameter -- rather special-purpose, I should think. And does it solve a problem that std::vector<> can't also solve? --- [ 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 ]