From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 09:14:00 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 657891065670 for ; Tue, 17 Feb 2009 09:14:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A98798FC13 for ; Tue, 17 Feb 2009 09:13:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA07675; Tue, 17 Feb 2009 11:13:45 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LZM1Q-0009gN-Un; Tue, 17 Feb 2009 11:13:45 +0200 Message-ID: <499A7FC6.40502@icyb.net.ua> Date: Tue, 17 Feb 2009 11:13:42 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) 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 Cc: Christoph Mallon , Marcel Moolenaar , 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:14:01 -0000 on 17/02/2009 03:52 Andrew Reilly said the following: > 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? Actually in that I example I see only definition of the interface and nothing about its implementation. The fact that that "String &operator[](size_t idx)" operator returns a reference to String doesn't mean that the class stores references. In fact, if return type of this operator was just "String" then it would mean that it returns a copy of a String. So it's impossible to judge what "the code that isn't there" would do. We could consider how vector works, which is very close to that interface (mucho simplified). First of all, actual array of string objects is stored in the vector. Then, in this case no temporary object is needed at all, because string has an assignment operator from const char *, which means that a string object knows how update itself when it is being assigned a const char * value. Also please see here: http://www.parashift.com/c++-faq-lite/references.html Section 8.3. > Conversely (and perhaps you will see my confusion): this other > paper: > http://codewrangler.home.comcast.net/~codewrangler/tech_info/cpp_compiler_tips.html > Under the section "Lifetime of Temporary Unnamed Objects" there > is a discussion about such temporary objects being reclaimed by > the language runtime as they go out of scope of the expression > in which they were created. So that sounds like either stack > allocation or heap allocation with explicit destructors inserted > when leaving scope. Either way, that would appear to render the > StringArray example above comprehensively broken, no? (The > array would contain a dangling reference when the temporary > String object is reclaimed at the end of the expression scope.) In general the following hold true: 1. temporary objects always have automatic scope which means that they are destroyed as soon as a scope where they were needed is left; compiler generates that code; 2. compiler would not allow to assign a pointer to a temporary object; it only allows to initialize a const reference with a temporary object, in which case the scope of the temporary is extended to be the same as the scope of that reference variable. 3. constructor of a temporary variable can, of course, allocate something on the heap (e.g. some sort of a buffer); its destructor must deallocate that memory; if it doesn't, then this just buggy code, nothing to do with temporaries. > This issue is, I believe, undecidable at compile time, and > goes by the name "escape detection". It is why *all* modern > object-oriented languages require garbage collection. Some > recent JIT runtime systems go to a great deal of effort to prove > that references to some objects do not "escape" the block, and > so can be stack-allocated and eagerly collected. That requires > whole-program analysis, which is something that a JIT can fudge, > but which a C++ compiler doing separate-compilation can't. No, no. C++ has stricter and simpler rules. It tries very hard to not allow a programmer to let any pointers/references to temporary objects escape. Of course, a sufficiently good programmer can still manage to make it happen, but then it's a programmer's problem - the temporary object would still not escape and be destroyed, the pointer/reference would point to garbage. It's like in C - you can return a pointer to a struct on stack, but that wouldn't make that struct magically be transfered to heap and persist, it would just make the returned pointer point to bad data. You might be also confused about what 'reference' in C++ is. In fact, Java references are very much alike C++ pointers (e.g. can be null, can be re-pointed). C++ references (when not abused through nasty tricks possible due to C compatibility) are just permanently-bound aliases. http://en.wikipedia.org/wiki/Reference_(C%2B%2B) I hope I managed to explain at least something, not made too many mistakes (I am not a big C++ expert recently) and not added to the confusion :-) -- Andriy Gapon