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