From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29367 invoked by alias); 21 May 2012 18:11:07 -0000 Received: (qmail 29254 invoked by uid 22791); 21 May 2012 18:11:05 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 May 2012 18:10:42 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4LI8gc5017176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 May 2012 14:10:42 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4LGRmJ2019730; Mon, 21 May 2012 12:27:49 -0400 Message-ID: <4FBA6D04.7060804@redhat.com> Date: Mon, 21 May 2012 18:11:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tom Tromey CC: Jan Kratochvil , gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> <8762cwpz3u.fsf@fleche.redhat.com> In-Reply-To: <8762cwpz3u.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00108.txt.bz2 On 04/18/2012 09:24 PM, Tom Tromey wrote: > Pedro> Even RAII is not _that_ different from cleanups. > > No, it really is. It is not dynamic, and you don't have to remember to > call do_cleanups on all exit paths. Cleanups are dynamic because they're been crafted that way. We could tweak cleanups to allow creating them on the stack. What I meant by not that different, is, that with RAII you get to write something like (the dumbest version of a RAII object that supports canceling possible): class my_raii_thing { private: whatever_arg *arg; << moral equivalent of the cleanup args. bool discarded; public: my_raii_thing (whatever_arg *p) : arg (p), discarded(false) {} ~my_raii_thing () << moral equivalent of a cleanup function. { if (!discarded) { // whatever to release this->arg or something like that. } } void discard () { discarded = true; } }; and then do: my_raii_thing foo (&whatever_arg); if (whatnot) { whatever_arg.discard(); return SUCESS; } } whereas we now write: struct cleanup_args { ... }; void foo_cleanup (void *arg) { // whatever to release this->arg or something like that. } and then: old_chain = make_cleanup (foo_cleanup, &whatever_arg); if (whatnot) { discard_cleanups (old_chain); return SUCESS; } do_cleanup (old_chain); But yes, as I've said before elsewhere, give me destructors, everything else I can live without. :-) Basically, whoever understands RAII should understand cleanups. Not counting the auto-destruction issue, I'm saying that writing raii classes vs writing cleanup function is mostly syntax sugar. > > I've fixed any number of memory (and, IIRC, file descriptor) leaks > caused precisely because cleanups are less good than RAII. > > Basically, with cleanups the default is full generality, but this is > wrong. With RAII the default is block scoping, and you have to expend > effort to do weird stuff. We could make make_cleanup return a reference to this instead of to the previous (as Doug suggested not long ago), and tweak cleanups to make it possible to have them on the stack, making their use follow scope closer too. -- Pedro Alves