маск не дал крису запилить теслу на свифте? )

https://twitter.com/clattner_llvm/status/877341760812232704

Онтопчик! https://github.com/FelixPetriconi/future_proposal/blob/v1.1/proposal.md

в тильдовой генте ещё не завезли

стяни 9999 компилятор из оверлея)

Онтопчик! https://github.com/FelixPetriconi/future_proposal/blob/v1.1/proposal.md

О, багу нашёл.

мне не настолько горит)

> In cases where error handling is necessary, an optional second argument to then can be used. Ну наконец то!

Наибольшая нагрузка на variant::variant(variant&&), просто потому, что чаще всего вызывается. Разумеется, все сборки с максимальной оптимизацией и с NDEBUG.

Часто в обоих ветках нужно иметь доступ к чему-то move constructible, что проблематично передать в обе лямбды. Было бы полезно поддержать передачу одной лямбды, которая принимает что-то вроде optional<R>.

@MatwayBurkow если есть, можете расшарить синтетический тест?

Поясните, что такое пропозалы

http://ideone.com/wxSYuh

вызовется только одна либо success, либо fail

Есть std::unique_ptr Его нужно передать куда-то дальше в обоих ветках. Как его передать в обе лямбды?

Есть std::unique_ptr Его нужно передать куда-то дальше в обоих ветках. Как его передать в обе лямбды?

Есть std::unique_ptr Его нужно передать куда-то дальше в обоих ветках. Как его передать в обе лямбды?

Может быть много других типов, которые не поддерживают копирование.

тогда их надо загонять под управление shared_ptr

А можно тупо копированием же, если данные небольшие)

ну я подразумевал, что как бы это не устраивает человека)

https://github.com/rbock/sqlpp11

Ну, куча шаблонной магии. Я, например, раньше написал замену std::tuple, которая плотно лежит (как структура). std::cout << sizeof(std::tuple<char, char, char, char, char, char, char, double>) << '\n'; --> 64 std::cout << sizeof(Matway::tuple<char, char, char, char, char, char, char, double>) << '\n'; --> 16

Msys2 mingw-64 auto tpl = std::tuple<char, char, char, char, double>(); std::cout << sizeof(tpl) << std::endl; // > 16

https://github.com/rbock/sqlpp11

а стоит ли это того, чтобы использовать? не легче ли поднять слой с REST сервисом, тем самым обеспечив интерфейсом не только C++ клиентов, но и JS и т.п.?

И про модули.

я просто кинул как интересную либу. В любом случае, всегда интересно иметь хоть какой-то интерфейс к БД. на дворе 2017 год, а С++ вот только узнал про файловую систему. Вот и БД на очереди

Но это только в C++20147.

долго жить ещё плюсам

с таким количеством уже написанного С++ кода нам работы до самой смерти есть. Это как Кобол

я просто кинул как интересную либу. В любом случае, всегда интересно иметь хоть какой-то интерфейс к БД. на дворе 2017 год, а С++ вот только узнал про файловую систему. Вот и БД на очереди

боюсь представить что будет к тому времени представлять из себя стандарт

вот хоть скриньте - поменяют поведение. Уберут consexpr и введут nonconstexpr какой-нибудь

По аналогии с throw/noexcept?

вот хоть скриньте - поменяют поведение. Уберут consexpr и введут nonconstexpr какой-нибудь