Cpluzplus: FeedaMail: Comments for Sutterâ€™s Mill

Comments for Sutter's Mill

Comment on Trip report: Fall 2015 ISO C++ standards meeting by Trip report: Summer ISO C++ standards meeting (Oulu) | Sutter's Mill

[…] already added to C++17). The new std::variant is a type-safe union; for more background see also my fall meeting trip report. Here's an example adapted from the paper that shows how you can use […]

Comment on Trip report: Winter ISO C++ standards meeting by Trip report: Summer ISO C++ standards meeting (Oulu) | Sutter's Mill

[…] C++17 is and tracking to ship on schedule next year. In my March trip report, I mentioned that after completing C++11 we switched to a "train model" where we have been […]

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Duarte

Great summary! Just one question: in the C++17 version of the demo, how is it okay to move twice from foo, in case the else branch is taken?

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Fabio

Addendum to my previous comment.

I do recognize there’d be no way for a std::*_ptr to both deduce its template argument and implement a forward constructor, because there’d be no way to know which class’ constructor the arguments oughta be forwarded to.

However, It’d be nice to be able to do something like this:

  std::unique_ptr<MyClass> myObject(arg1, arg2, arg3);

instead of doing

  auto myObject = make_unique<MyClass>(arg1, arg2, arg3);

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Sebastian Hofstetter

  void f(string_view id, unique_ptr<Foo> foo) {     if (auto [pos, inserted] = items.try_emplace(id, move(foo)); inserted){        pos->second->launch();     } else {        standby.emplace_back(move(foo))->wait_for_notification();     }  }

Would it be possible to nest structured bindings like so?:

  void f(string_view id, unique_ptr<Foo> foo) {     if (auto [*[new_id, new_foo], inserted] = items.try_emplace(id, move(foo)); inserted){        new_foo->launch();     } else {        standby.emplace_back(move(foo))->wait_for_notification();     }  }

I really want to get rid of those error-prone and confusing “->first” and “->second” statements in my code alltogether.

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by sv90

One question about structured bindings:
Will this be possible in C++17?

  map<int, string> mymap;  //...  for (auto [key, value] : mymap) {   //...  }

If not, is there a special reason why this is not desirable?

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by admin

This looks incorrect in your structured binding example:

  else if constexpr(I == 1) return string_view{c}; }

It should be:

  else if constexpr(I == 1) return string_view{x.c};

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Fabio

First off, great job!

I’m especially gonna love the “template argument deduction for constructors”, what about the std::*_ptr classes though? In one of your past posts you showed an implementation of make_unique whose usefulness goes beyond just saving keystrokes, having more to do with exception safety.

Correct me if I’m wrong, to be consistent with the new change, std::unique_ptr and std::shared_ptr would have to have a forwarding constructor: will that be the case?

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Furkan

In C++17 version

wouldn’t items.try_emplace(id, move(foo)
move foo even if it doesn’t emplace,
and then using it in the else block result in undefined behaviour

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Andrzej Krzemieński

Thanks for the report! It must have been a busy week.

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Marcin

The example with if-constexpr’ed get, shouldn’t this get() be BFF with S? The rule of accessing members (here, private members) didn’t change, did it?

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by Mark Isaacson

Thanks for the timely update! The reference to my talk is also much appreciated :). Hoping we’ll cross paths at CppCon.

One specific unfortunate example where the const string& -> string_view conversion breaks down that a colleague discovered recently is in functions that need to search an unordered_map. As of C++14 map has the ability to compare with types other than key_type, but unordered_map’s find function won’t accept anything other than key_type. I’d expect std::hash to be the same as std::hash… so… hoping there’s something to be done in this space. Willing to try and put forward a proposal if it sounds like a worthy cause to you/if I’m not missing an obvious blocker.

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by howardhinnant

Really nice update! Thanks Herb!

Comment on Trip report: Summer ISO C++ standards meeting (Oulu) by GregM

“When the proposal got to the full committee, we discovered that the committee didn't have consensus to approve the paper's opt-out model; a number of people spoke up for an opt-in model instead. This proposal might eventually come back but probably not soon.”

That’s too bad. Is there a summary of the reasons that were given for not approving the paper’s opt-out model?

(Sponsor this newsletter)

Delievered to you by Feedamail.
Unsubscribe

Cpluzplus

Friday, July 1, 2016

FeedaMail: Comments for Sutterâ€™s Mill

No comments:

Post a Comment