From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 01:53:05 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 F00B2106566B for ; Tue, 17 Feb 2009 01:53:05 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id 826388FC12 for ; Tue, 17 Feb 2009 01:53:05 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20090217015253.QSAS16649.nschwmtas03p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Tue, 17 Feb 2009 01:52:53 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090217015249.YVU7357.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 17 Feb 2009 01:52:49 +0000 Received: (qmail 25618 invoked by uid 501); 17 Feb 2009 01:52:48 -0000 Date: Tue, 17 Feb 2009 12:52:48 +1100 From: Andrew Reilly To: Andriy Gapon Message-ID: <20090217015248.GC21644@duncan.reilly.home> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49992A68.8010702@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.499A1871.009C,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: Tue, 17 Feb 2009 01:53:06 -0000 Hi Andriy, I'm responding to this again in the hope that someone with a better grasp of C++ than me will be able to explain to me how this situation is avoided. This is one of the big reasons why I rejected C++ after some seven or so years of exclusive use. That was back in about 1996 or so, so I admit that things might have changed or improved in the meantime.) This is almost certainly off-topic for -current, so please ignore the rest of this thread if it doesn't interest you... 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? 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.) 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. > As to the conversions through constructors, conversion operators and > implicit type promotions - I personally had much less incidents because > of that than I had incidents in C with passing/casting something > incorrect via void*. This is to say that C++ is far from perfect and > there are languages that are much better than it, but C is even (much) > less perfect. > And of all languages out there, I think, that C++ comes closest to a > definition of "enriched", "better", "fortified" C. Which implies much > lower entry barrier (and possibility for limited/gradual introduction). I think that C++ was a noble try at an improvement in 1985, but has far too many warts and sharp edges for general use, and has been comprehensively superceded by languages that use garbage collection. Yes, C has sharp edges too, but it also has less magic: it is much (much) closer to assembly language in that regard. Sometimes that is appropriate (I think that it is, where operating systems are concerned), and sometimes not. When I'm not writing in C, I use python or scheme (or Matlab), not C++. Luckily, hardly anyone cares what I think :-) Cheers, -- Andrew