Date: Wed, 18 Feb 2009 13:42:07 +1100 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: Christoph Mallon <christoph.mallon@gmx.de>, Marcel Moolenaar <xcllnt@mac.com>, Bruce Simpson <bms@incunabulum.net>, freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys Message-ID: <20090218024207.GA87916@duncan.reilly.home> In-Reply-To: <499A7FC6.40502@icyb.net.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090218024207.GA87916>