From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 09:26:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A764106566C for ; Tue, 17 Feb 2009 09:26:58 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id BE8698FC0A for ; Tue, 17 Feb 2009 09:26:57 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 17 Feb 2009 09:26:55 -0000 Received: from p54A3F33E.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.243.62] by mail.gmx.net (mp008) with SMTP; 17 Feb 2009 10:26:55 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19BTDgiinNBkJRxV1LA9byWWNrxMuIuAciW4M1NA2 KWYidTlxdTZXfU Message-ID: <499A82DE.3080701@gmx.de> Date: Tue, 17 Feb 2009 10:26:54 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Andrew Reilly References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> <20090216055602.GA70145@duncan.reilly.home> <49992A68.8010702@icyb.net.ua> <20090217015248.GC21644@duncan.reilly.home> In-Reply-To: <20090217015248.GC21644@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: Marcel Moolenaar , Andriy Gapon , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 09:26:58 -0000 Andrew Reilly schrieb: > On Mon, Feb 16, 2009 at 10:57:12AM +0200, Andriy Gapon wrote: >> on 16/02/2009 07:56 Andrew Reilly said the following: >> This is the first time in my life that I hear about temporary objects on >> the heap and/or memory leaks through temporary objects. Either you are >> remembering a bug in some ancient C++ compiler or you are referring to >> some buggy code. > > Well, code that results in a memory leak (or dangling reference) > is buggy by definition, but how to avoid it, in general? I'm > not about to write some examples for the purpose of this > discussion, so google searches will have to do. > > The first google search that I did for "C++ argument promotion > temporary objects" came up with this link: > http://www.icce.rug.nl/documents/cplusplus/cplusplus09.html > > If you skip down to the StringArray example, you can see that > a new String object is automatically constructed to cast the > char* to fit the String &operator[](size_t idx) method. Now, > in this instance the constructed object has somewhere to go: a > reference is being stored in the array. So the temporary object > must have been constructed on the heap. But other methods on > other objects may require String arguments, invoking the same > constructor, but they might not record the reference and so it > won't be cleaned up later. Or will it? Uh, your observation is wrong. I guess you talk about the line sa[3] = "hello world"; because this is the only line, which includes vaguely something like a char*[0]. The text describes in detail what happens. Actually there are no temporary objects involved. First sa[3] is evaluated. The left hand side of the [] operator is a StringArray and the right hand side is an integer literal. The overloaded [] operator in class StringArray fits here, so we get a reference to a String, i.e. a String&, as result. Then there is the = operator. On the left side is a String& and on the right side (after default conversion) a const char*. We look in class String and find an overloaded = operator, which takes a const char* as second argument, so this one is called. The sa[3] part knows nothing at all about the string literal later. The string literal knows nothing about the sa[3] either. Their only connection is the = operator, which knows both its operands, of course. End of story. [0] A string literal is of type const char[] and there is a deprectaed conversion from string literals to char*, but this is not necessary here, because we only need a const char* which is fine.