FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Anthony (Andy) Hall (@Spamthrond) I’m curious, with template argument deduction for constructors obviating the need for most make_*() functions, if make_shared() will still be required if we want the reference counting control block to be allocated alongside the actual object data, or if that optimization can also now be handled via the share_ptr constructor directly. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by tcanens @Duarte/Furkan try_emplace is guaranteed to not touch its arguments if the key already exists in the container. That’s approximately the whole point of it. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by GregM The other half of that answer is the entire reason for try_emplace, the guarantee that it won’t move from the object if it already exists and thus isn’t added. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by GregM move(foo) does not move from foo. It simply says that foo is eligible to be moved from. A less confusing name would have been rvalue_cast(), and I think that was discussed at one point but it was too late in the process to make that change. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by hyrosen To the couple of people asking about the twin calls to std;:move, std::move itself does nothing except cast its argument to an rvalue reference, so you can call it on an object as many times as you want. It’s the thing that receives an rvalue reference that can muck about with the innards of the object, and try_emplace promises not to do that if the key is already there. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by sv90 To answer my own question here: According to this paper http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0144r2.pdf (section 2.5) it will be possible to use structured bindings in for loops. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Andrzej Krzemieński @Duarte: In the C++17 example foo is not moved from twice. It is only converted to an rvalue reference twice. Function try_emplace now may or may not move from the object, depending on whether it would be a duplicate or not. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Andrzej Krzemieński @sv90: the for-each loop works with structured bindings. Your example is correct under P0217R3: map<int, string> mymap; //... for (auto [key, value] : mymap) { //... } Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by KyleK @Duarte [std::move(foo)] simply casts to an rvalue reference but it does not actually perform the move itself. If [try_emplace] returns false, then ownership of [foo] has not been claimed, but [foo] just hangs around as an rvalue reference. In that case, the else branch will perform a second [std::move(foo)], which just performs another rvalue-reference cast. An rvalue-reference cast on top of an rvalue reference results in just an rvalue reference. So nothing dangerous happening. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Dan Haffey @Fabio: The problem with a forwarding ctor on unique_ptr is that it’d either be dangerous in the case of a single pointer argument, or inconsistent if it only forwarded multiple arguments. Imagine if MyClass had a constructor like MyClass(MyClass* parent); , where the parent is assumed to outlive the constructed instance. Then unique_ptr<MyClass>(parent) would lead to a double-delete instead of constructing a new instance. You could fix that by requiring a tag as the first argument, kinda like std::pair does with std::piecewise_construct : unique_ptr<MyClass>(std::construct_new, parent); But at that point it doesn’t seem like much of a win compared to make_unique . Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by GregM Wow, I guess there was a bit of a moderation delay getting those replies posted. Six answers written before any of them appeared. Andy, I don’t imagine it will be possible to eliminate make_shared. The constructor can’t possibly do it because the allocated memory block needs to be larger than shared_ptr itself. By the time the constructor is called, it’s too late to affect that. Read More » Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Giuseppe Really helpful as usual Herb, the only thing that worries me is that at this level of innovation it is becoming very difficult to keep track of everything… someone is still struggling to introduce modern c++11 in production. We need more books and publications, We, average Joe programmers, need some guidance I think the effort with GSL is awesome i think! Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe