From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 02:42:49 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 6FEA4106566B for ; Wed, 18 Feb 2009 02:42:49 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id 04E188FC1B for ; Wed, 18 Feb 2009 02:42:48 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20090218024247.PVXI3101.nschwmtas06p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Wed, 18 Feb 2009 02:42:47 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090218024243.FSDY7357.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 18 Feb 2009 02:42:43 +0000 Received: (qmail 93053 invoked by uid 501); 18 Feb 2009 02:42:07 -0000 Date: Wed, 18 Feb 2009 13:42:07 +1100 From: Andrew Reilly To: Andriy Gapon Message-ID: <20090218024207.GA87916@duncan.reilly.home> References: <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> <499A7FC6.40502@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499A7FC6.40502@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.499B75A4.011D,ss=1,fgs=0 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: Wed, 18 Feb 2009 02:42:49 -0000 On Tue, Feb 17, 2009 at 11:13:42AM +0200, Andriy Gapon wrote: > on 17/02/2009 03:52 Andrew Reilly said the following: > 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. OK, that seems pretty clear (if quite limited, compared to more dynamic languages). > >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. Thanks for that clear explanation. I hadn't noticed that the array of Strings was already allocated, so there wasn't any allocation going on of the temporary. I guess that the restriction for const references in these sorts of situations ensures that any callee that wants to maintain a pointer/reference to the source has to do a copy. > 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 Thanks very much (both you and Christoph) for the explanation. I think that I have a much better understanding of where C++ is coming from, now. It is, of course, not too different from the sorts of things that one does in C, just with more under-the-covers magic to help things along. I don't think that it's to my taste though, and the incredible complexity and ugly syntax will ensure that I continue to avoid it as much as I can. Maybe when the follow-up to C++0x adds garbage collection... Cheers, Andrew