Comments on: Shaving some time http://www.frozentux.net/2010/05/shaving-some-time/ Yet another site Thu, 26 Jan 2012 01:46:05 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Oskar Andreasson http://www.frozentux.net/2010/05/shaving-some-time/comment-page-1/#comment-430 Oskar Andreasson Thu, 10 Feb 2011 19:41:05 +0000 http://www.frozentux.net/?p=605#comment-430 Yupp, you are both correct. There are several errors in that code. However, the interesting part isn't the return value per se, but the time difference in using a reference vs pointer and the cost of new/delete. Exactly as you both pointed out ;) . Yupp, you are both correct. There are several errors in that code. However, the interesting part isn’t the return value per se, but the time difference in using a reference vs pointer and the cost of new/delete. Exactly as you both pointed out ;) .

]]> By: J Austin http://www.frozentux.net/2010/05/shaving-some-time/comment-page-1/#comment-429 J Austin Sun, 06 Feb 2011 03:28:55 +0000 http://www.frozentux.net/?p=605#comment-429 Carl-Erwin is correct. The reference case uses a variable allocated on the stack and the reference that is returned is undefined because the referenced stack object no longer exists. You would be better off to not use new and delete and just return a pointer to a variable on the stack. Violate the language in the same way in both cases. I'll bet performance is the same if you do it that way. Carl-Erwin is correct. The reference case uses a variable allocated on the stack and the reference that is returned is undefined because the referenced stack object no longer exists.

You would be better off to not use new and delete and just return a pointer to a variable on the stack. Violate the language in the same way in both cases. I’ll bet performance is the same if you do it that way.

]]> By: Carl-Erwin Griffith http://www.frozentux.net/2010/05/shaving-some-time/comment-page-1/#comment-350 Carl-Erwin Griffith Tue, 09 Nov 2010 10:00:07 +0000 http://www.frozentux.net/?p=605#comment-350 Hi, The overhead you seen is caused by new/delete function calls and the returned reference points into the stack :-) Hi,

The overhead you seen is caused by new/delete function calls
and the returned reference points into the stack :-)

]]>