Comments for C++Next http://cpp-next.com The next generation of C++ Mon, 30 Apr 2012 15:07:48 +0000 hourly 1 http://wordpress.org/?v=3.3.2 Comment on Implicit Move Must Go by Dave Abrahams http://cpp-next.com/archive/2010/10/implicit-move-must-go/comment-page-1/#comment-1935 Dave Abrahams Mon, 30 Apr 2012 15:07:48 +0000 http://cpp-next.com/?p=2711#comment-1935 <p>We do have it in C++11. I don't think it'll be changed—the damage has been done; can't un-ring that bell. I don't know about the compiler warning; I haven't seen one</p> We do have it in C++11. I don’t think it’ll be changed—the damage has been done; can’t un-ring that bell. I don’t know about the compiler warning; I haven’t seen one

]]> Comment on Implicit Move Must Go by Martin Ba http://cpp-next.com/archive/2010/10/implicit-move-must-go/comment-page-1/#comment-1934 Martin Ba Mon, 30 Apr 2012 06:45:15 +0000 http://cpp-next.com/?p=2711#comment-1934 <p>@Dave - Since you linked this example on April 3rd 2012 ... is this still something you think might be changed in a future standard? (I mean, we do have implicit move in the current C++11 now, do we?)</p> <p>Has anyone come up with a sane compiler-warning regarding this issue?</p> <p>cheers, Martin</p> @Dave – Since you linked this example on April 3rd 2012 … is this still something you think might be changed in a future standard? (I mean, we do have implicit move in the current C++11 now, do we?)

Has anyone come up with a sane compiler-warning regarding this issue?

cheers, Martin

]]> Comment on Implicit Move Must Go by Dave Abrahams http://cpp-next.com/archive/2010/10/implicit-move-must-go/comment-page-1/#comment-1926 Dave Abrahams Tue, 03 Apr 2012 01:48:05 +0000 http://cpp-next.com/?p=2711#comment-1926 <p>Note: real-world manifestation of this issue can be observed at http://j.mp/implicit-move-bites-man</p> Note: real-world manifestation of this issue can be observed at http://j.mp/implicit-move-bites-man

]]> Comment on Want Speed? Pass by Value. by Howard Hinnant http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/comment-page-1/#comment-1925 Howard Hinnant Mon, 02 Apr 2012 20:42:49 +0000 http://cpp-next.com/?p=188#comment-1925 <p>That sounds right.</p> That sounds right.

]]> Comment on Want Speed? Pass by Value. by Andrea http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/comment-page-1/#comment-1924 Andrea Mon, 02 Apr 2012 20:34:51 +0000 http://cpp-next.com/?p=188#comment-1924 <p>Howard, thanks for your helpful reply. I think I'm getting hold of it now. Can you just confirm my understanding is right when I say that: When using vectors of object that have "external" resources (i.e. allocate memory on the heap as it is the case for strings), going through the route of invoking their constructor (as when doing ::new(end_) T(v[i]) in the copy constructor loop used when -DUSE_SWAP_ASSIGNMENT) makes you incur in the penalty of allocations even if those are placement news. Instead, the <em>p=</em>q assignments in the plain old assignment operator's loop can re-use the already allocated memory on the destination (in particular when as in this case, the destination is a longer string) and make this approach more efficient. As you suggested, using vectors of int (or I think more generally PODs/aggregate objects) levels out the difference of the two approaches because that extra price during the placement new has not to be payed.</p> <p>Andrea</p> Howard, thanks for your helpful reply. I think I’m getting hold of it now. Can you just confirm my understanding is right when I say that: When using vectors of object that have “external” resources (i.e. allocate memory on the heap as it is the case for strings), going through the route of invoking their constructor (as when doing ::new(end_) T(v[i]) in the copy constructor loop used when -DUSE_SWAP_ASSIGNMENT) makes you incur in the penalty of allocations even if those are placement news. Instead, the p=q assignments in the plain old assignment operator’s loop can re-use the already allocated memory on the destination (in particular when as in this case, the destination is a longer string) and make this approach more efficient. As you suggested, using vectors of int (or I think more generally PODs/aggregate objects) levels out the difference of the two approaches because that extra price during the placement new has not to be payed.

Andrea

]]> Comment on Want Speed? Pass by Value. by Howard Hinnant http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/comment-page-1/#comment-1923 Howard Hinnant Fri, 30 Mar 2012 19:41:05 +0000 http://cpp-next.com/?p=188#comment-1923 <p>Think of it this way: the most efficient way to recycle something is to re-use it. The copy assignment operator can sometimes re-use memory, instead of deallocating it and then allocating more. That is what is happening in this example. One way deallocates memory just to turn around and allocate it back. The other way holds on to its memory and re-uses it for the new value. The optimization is to simply avoid calling new/delete as much as you can.</p> <p>I imagine the difference you're seeing with gcc is that they are using a ref-counted string. Try the experiment again, but using MyVector<std::vector<int>> instead.</p> Think of it this way: the most efficient way to recycle something is to re-use it. The copy assignment operator can sometimes re-use memory, instead of deallocating it and then allocating more. That is what is happening in this example. One way deallocates memory just to turn around and allocate it back. The other way holds on to its memory and re-uses it for the new value. The optimization is to simply avoid calling new/delete as much as you can.

I imagine the difference you’re seeing with gcc is that they are using a ref-counted string. Try the experiment again, but using MyVector<std::vector<int>> instead.

]]> Comment on Want Speed? Pass by Value. by Andrea http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/comment-page-1/#comment-1922 Andrea Thu, 29 Mar 2012 16:16:50 +0000 http://cpp-next.com/?p=188#comment-1922 <p>Wow! Tried to understand what's going on here... Am I right in assuming the difference is in the ::new(end_) T(v[i]) copy construction loop in cctor (used when -DUSE_SWAP_ASSIGNMENT) vs the *p = *q assignment loop when using "normal" MyVector& operator=(const MyVector &) ??? But then why such a difference? There's a placement new up there (i.e. not real memory allocations, only string's cctor invocation), how can it be that worse than an assignment? I'm sure I'm missing something... Also, testing on a mac with latest clang from trunk and gcc-4.7 built from sources, I can't see that timing difference when compiling with g++ -std=c+11. I.e., both old and swap-based assignments time almost the same as clang's best case. Is the different size of std::string (8 bytes in gnu's libstdc++ vs 24 bytes in clang's libc++) the cause of gcc's insensitivity to the kind of assignment used?</p> <p>Andrea</p> Wow! Tried to understand what’s going on here… Am I right in assuming the difference is in the ::new(end_) T(v[i]) copy construction loop in cctor (used when -DUSE_SWAP_ASSIGNMENT) vs the *p = *q assignment loop when using “normal” MyVector& operator=(const MyVector &) ??? But then why such a difference? There’s a placement new up there (i.e. not real memory allocations, only string’s cctor invocation), how can it be that worse than an assignment? I’m sure I’m missing something… Also, testing on a mac with latest clang from trunk and gcc-4.7 built from sources, I can’t see that timing difference when compiling with g++ -std=c+11. I.e., both old and swap-based assignments time almost the same as clang’s best case. Is the different size of std::string (8 bytes in gnu’s libstdc++ vs 24 bytes in clang’s libc++) the cause of gcc’s insensitivity to the kind of assignment used?

Andrea

]]> Comment on Having it all: Pythy syntax for C++ by Paul http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/comment-page-1/#comment-1918 Paul Sat, 24 Mar 2012 16:11:51 +0000 http://cpp-next.com/?p=3972#comment-1918 <p>I really hope this gets added to C++ soon. This would fix so many problems with lambdas. Currently, lambdas in C++, trap you in a monomorphic box that you can't get out. So, in C++11, I have to use named functions and Boost.Phoenix, just like I did in C++03.</p> <p>I know Bjarne Stroustrup had mentioned adding one new language feature for TR2(which it seems is no longer called TR2). However, polymorphic lambdas is not just a language feature, its more like a "bug" fix. At least, if the committee doesn't want to add polymorphic lambdas yet, they could at least improve type deduction for lambdas and the use of lambdas as class members, since polymorphic lambdas would open the door to local templates.</p> <p>Finally, I think that adding your proposed syntax for functions first, could be a nice transition into polymorphic lambdas.</p> I really hope this gets added to C++ soon. This would fix so many problems with lambdas. Currently, lambdas in C++, trap you in a monomorphic box that you can’t get out. So, in C++11, I have to use named functions and Boost.Phoenix, just like I did in C++03.

I know Bjarne Stroustrup had mentioned adding one new language feature for TR2(which it seems is no longer called TR2). However, polymorphic lambdas is not just a language feature, its more like a “bug” fix. At least, if the committee doesn’t want to add polymorphic lambdas yet, they could at least improve type deduction for lambdas and the use of lambdas as class members, since polymorphic lambdas would open the door to local templates.

Finally, I think that adding your proposed syntax for functions first, could be a nice transition into polymorphic lambdas.

]]> Comment on Implicit Move Must Go by CM http://cpp-next.com/archive/2010/10/implicit-move-must-go/comment-page-1/#comment-1917 CM Thu, 22 Mar 2012 16:51:14 +0000 http://cpp-next.com/?p=2711#comment-1917 <p>Dave, you do not want to respond? but what about community? I am sure they are looking forward for us to continue... ;-)</p> Dave, you do not want to respond? but what about community? I am sure they are looking forward for us to continue… ;-)

]]> Comment on Implicit Move Must Go by Marc http://cpp-next.com/archive/2010/10/implicit-move-must-go/comment-page-1/#comment-1916 Marc Wed, 21 Mar 2012 18:50:36 +0000 http://cpp-next.com/?p=2711#comment-1916 <blockquote cite="comment-1914"> <strong><a href="#comment-1914" rel="nofollow">CM</a></strong>: Can’t believe someone actually reads or tracks comments to 1 year old blog post… </blockquote> <p>Well, they set up a nice global RSS for the whole site...</p> CM: Can’t believe someone actually reads or tracks comments to 1 year old blog post…

Well, they set up a nice global RSS for the whole site…

]]>