From -4845953474363146803 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,a0fcd8899dc05427 X-Google-Attributes: gidf78e5,public From: kanze@gabi-soft.fr (J. Kanze) Subject: Re: Implicit smart-to-dumb pointer conversions Date: 1996/06/03 Message-ID: #1/1 X-Deja-AN: 158251697 references: <4ognb0$3cd@linda.teleport.com> <4okqhp$lgd@bmtlh10.bnr.ca> x-original-date: 01 Jun 1996 07:40:27 GMT organization: GABI Software, Sarl. x-auth: PGPMoose V1.1 PGP comp.std.c++ newsgroups: comp.std.c++ originator: austern@isolde.mti.sgi.com In article <4okqhp$lgd@bmtlh10.bnr.ca> "john (j.d.) hickin" writes: |> Scott Meyers (commenting on a suggestion to augment auto_ptr): |> Right. But remember that compilers use implicit type con- |> versions to make function calls succeed whenever they can, and recall |> that use of the delete operator leads to calls to a destruc- |> tor and to operator delete, both of which are functions. Compilers |> want these function calls to succeed, so in the delete statement |> above, they implicitly convert pt to a Tuple*, then they delete that. |> This will almost certainly break your program. |> It seems here that this argument allows compilers to accept the following: |> char b[1]; |> delete[] b; |> Indeed my favourite compiler accepts it [I thought it was corrected 1 release |> ago but like the cat, it came back :-)]. It must accept it (unless it does complete flow analysis, and can prove that the delete statement actually gets executed), since it is perfectly legal C++. A warning wouldn't be a bad thing, however. |> On the other hand, gcc 2.7.2 rejects the above code, as does it reject |> delete ptr; // where *ptr is a class with operator T*(); This sounds like a bug, not a feature:-). Although again, a warning would be nice. |> I suppose this is yet another case where we argue that compilers might detect |> these problems but shouldn't be oblidged to do so. |> BTW, I work around the problem by adding a private operator void*() to the |> smart pointer class. Clever. But I find it easier not to support the conversion to begin with. If I really need the raw pointer, there is always a get function (or &*smartPtr). -- James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France Conseils en informatique industrielle -- -- Beratung in industrieller Datenverarbeitung --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]