From 3187025445527317653
X-Google-Thread: f78e5,a10702d4a7db0a94
X-Google-Attributes: gidf78e5,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: g2news2.google.com!news2.google.com!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news-fra1.dfn.de!newsfeed.hanau.net!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull
From: pixi@bloodbath.burble.org (maurice barnum)
Newsgroups: comp.std.c++
Subject: Re: Why no size_t to ::operator delete?
Date: Tue,  9 Jan 2007 05:48:10 GMT
Organization: UseNetServer.com
Lines: 49
Sender: mail2news@demon.net
Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++)
Message-ID: <m2y7oc99xt.fsf@bloodbath.burble.org>
References: <12pl7grpv7f7sde@corp.supernews.com>
 	<memo.20070104213729.3724A@brangdon.cix.compulink.co.uk>
 	<12pu12q67i8oob6@corp.supernews.com>
 	<459fe57f$0$24160$426a34cc@news.free.fr>
NNTP-Posting-Host: news.news.demon.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: news.demon.co.uk 1168321706 4658 158.152.254.254 (9 Jan 2007 05:48:26 GMT)
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: Tue, 9 Jan 2007 05:48:26 +0000 (UTC)
X-Original-To: std-c++@mailman.ucar.edu
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
X-User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (gnu/linux)
X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au
X-Cancel-Lock: sha1:Xmixhy5WIkADkUbnjzSTSCqMm3Y=
X-Received: (from fjh@localhost)
	by mulga.csse.unimelb.edu.au (8.13.8+Sun/8.13.8/Submit) id l095mAmo027935;
	Tue, 9 Jan 2007 16:48:10 +1100 (EST)
X-Path: comp-std-cpp-robomod!not-for-mail
X-Delivered-To: std-c++@mailman.ucar.edu
X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f
X-Newsgroups: comp.std.c++
Xref: g2news2.google.com comp.std.c++:5298

loufoque@remove.gmail.com (Mathias Gaunard) writes:

> struct A
> {
>     virtual ~A() = 0;
> }
>
> struct B : public A
> {
>     ~B() { }
> }
>
> int main()
> {
>     B b;
>     A& a = b;
>     a.~A();
> }
>
> If the destructor called operator delete here, it would do so on an
> object allocated on automatic memory, hence invoking undefined
> behaviour.

[are we wandering off-topic into implementation specifics?]

the implementations i've looked at do in fact have the destructor
call the appropriate operator delete, but that call is conditional
upon a parameter passed by the compiler.  if we imagine the
B::~B() being translated to C, you'd see something like

        void __B_dtor(B* self, int do_delete)
        {
            __B_user_dtor(self);
            __B_cleanup(self);
            __A_dtor(self, 0);
            if (do_delete)
               __B_operator_delete(self);
        }

except the __B_* functions would probably just be inlined
code to execute the user define destructor, member cleanup,
and call the appropriate operator delete, respectively.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]