даже сформулировать по-людски не могут )

Z x{-1} это explicit выражение

да и т.к. Z это unsigned int, то он не допускает то, что не может сконвертить в unsigned int

да и т.к. Z это unsigned int, то он не допускает то, что не может сконвертить в unsigned int

не допускает explicit int но допускает implicit?

Z x{-1} это explicit, Z x = -1 это implicit

using Z = unsigned int;

первое не работает, второе работает

второе работает из-за обратной совместимости

а первое не работает из-за совместимости

а первое не работает, потому что там не нужна обратная совместимость

так что смысл выражения в точности инвертируется в зависимости от user-defined типа

в случае с user-defined типом там в обоих местах не нужна обратная совместимость

т.е. грубо говоря это кнопка, которая при нажатии правым мизинцем включает чайник, при нажатии левым мизинцем запускает машину судного дня

не перепутай

в случае с user-defined типом там в обоих местах не нужна обратная совместимость

к черту подробности, как написать "инициализировать только если implicit" и как написать "инициализировать как explicit"

по логике современного C++ при Z = unsigned int оба места не должны компилироваться

если бы не нужна была обратная совместимость

но т.к. обратная совместимость нужна

наверни говна )

вы вообще понимаете что я спрашиваю?

вы вообще понимаете что я спрашиваю?

нет

но давай ограничимся только user-defined типами

нет

почему поведение синтаксической конструкции строго инвертируется для user defined типа

и как синтаксически выразить инициализацию с implicit и explicit требованием

ничего не мешает навернуть свой user-defined unsigned int

ничего не мешает навернуть свой user-defined unsigned int

сделай

повторив поведение unsigned int

повторив поведение unsigned int

какое именно поведение?

какое именно поведение?

ладно, давайте вопрос на знание языка

что будет если Z это std::byte?

что будет если Z это std::byte?

оба места будут с ошибками

оба места будут с ошибками

что будет если Z это std::byte и инициализатор 1?

Ребят, подскажите, пожалуйста. auto sock = std::make_shared<boost::asio::ip::tcp::socket>( ioc, ep.protocol() ); sock-> async_connect( ep, [s= std::move(sock) ](auto && ...args){...} ); это undefined behaviour?

что будет если Z это std::byte и инициализатор 1?

второе место не скомпилируется

второе место не скомпилируется

т.е. std::byte это user-defined тип, правильно?

т.е. std::byte это user-defined тип, правильно?

да

да

т.е. в C++ по-прежнему нельзя создать integer strong alias?

т.е. в C++ по-прежнему нельзя создать integer strong alias?

а так ли нужна запись с =? тем более, что можно написать auto y = std::byte{1};

её набрать можно быстрее например

или сделать user-defined литерал 1_byte

и читается лучше

а суффиксы эти вообще дичь

или сделать user-defined литерал 1_byte

хотя это уже больше похоже на единицу измерения

а так ли нужна запись с =? тем более, что можно написать auto y = std::byte{1};

скомпилируется ли std::vector<unsigned int> v; v.push_back(-1); ?

скомпилируется ли std::vector<unsigned int> v; v.push_back(-1); ?

да

что из следующего компилируется: std::vector<unsigned int> v (-1); std::vector<unsigned int> v {-1}; std::vector<unsigned int> v = { -1 };

да

ссылку на стандарт, пожалуйста

что из следующего компилируется: std::vector<unsigned int> v (-1); std::vector<unsigned int> v {-1}; std::vector<unsigned int> v = { -1 };

только первое

и то же самое - ссылку на стандарт для emplace_back

только первое

template <typename T, typename... Args> void f(Args&&... args) { T x{std::forward<Args>(args)...}; } void foo() { f<unsigned int>(-1); }

так тебе ссылку на push_back или ссылку на implicit конверсии из signed в unsigned?

так тебе ссылку на push_back или ссылку на implicit конверсии из signed в unsigned?

что emplace_back компилируется

@antoshkka репортните там в gcc https://godbolt.org/z/SDaOeW

что emplace_back компилируется

emplace_back компилируется, потому что там конструируется через круглые скобки

emplace_back компилируется, потому что там конструируется через круглые скобки

так в стандарте и написано? конструируется круглыми скобками?

так в стандарте и написано? конструируется круглыми скобками?

на cppreference да, ща в стандарте поищу

так в стандарте и написано? конструируется круглыми скобками?

http://eel.is/c++draft/sequence.reqmts#tab:containers.sequence.optional a.emplace_­back(args) строчка в таблице

на cppreference да, ща в стандарте поищу

https://en.cppreference.com/w/cpp/memory/allocator_traits/construct точнее вот, использует это

http://eel.is/c++draft/sequence.reqmts#tab:containers.sequence.optional a.emplace_­back(args) строчка в таблице

а вот в стандарте что-то не могу найти где это точно написано, нахожу только такое: http://eel.is/c++draft/container.requirements#general-15.5

а вот в стандарте что-то не могу найти где это точно написано, нахожу только такое: http://eel.is/c++draft/container.requirements#general-15.5

А что найти хочешь?

А что найти хочешь?

то, что emplace_back конструирует используя allocator_traits<...>::construct

А что найти хочешь?

нашёл у vector<bool> http://eel.is/c++draft/vector.bool#2: Unless described below, all operations have the same requirements and semantics as the primary vector template, except that operations dealing with the bool value type map to bit values in the container storage and allocator_­traits​::​construct is not used to construct these values. идём от противного

А что найти хочешь?

http://eel.is/c++draft/container.requirements#general-3 скорее всего это то, что нужно

Тоесть нельзя мне delete к выделенному кусочку памяти применять?

нельзя. Можно только если ты его перегрузил. Если хочешь удолить класс, то можно жахнуть так: YourClass->~Dtor();

Чем отличается семафор и двоичный семафор в Windows api или они ни чем не отличаются?

тем, что один не двоичный (т.е. его можно захватить N раз), а второй мутех

тем, что один не двоичный (т.е. его можно захватить N раз), а второй мутех

это который shared_mutex или как там его?

ну unsigned int = -1; используется на практике, самое большое число получить, хотя это непереносимый код

лучше UINT_MAX жмякнуть

это который shared_mutex или как там его?

в C++ да, в Win API, про который был вопрос - это тот, что создается через CreateSemaphore

в C++ да, в Win API, про который был вопрос - это тот, что создается через CreateSemaphore

я просто к тому, что вроде mutex / shared_mutex точное соответствие, хотя я не изучал деталей

ну концептуально да, по факту я не хочу ща ночью по стандартам и реализациям лазить и смотреть)

ну концептуально да, по факту я не хочу ща ночью по стандартам и реализациям лазить и смотреть)

там же ноги к read/write растут?

возможно. ничего не хочу говорить точно, чтобы не ошибиться, голова не варит уже, честно говоря

а я не помню, объект, который обновляет состояние нескольких итераторов в range-based-for, в итоге приняли в 20-й стандарт? (я про некий аналог zip)

я о такой фигне: vector vec1, vec2; for (auto [it1, it2] : zip(vec1, vec2)) { // что-то делаем с итераторами и двигаемся по ним одновременно... }

я о такой фигне: vector vec1, vec2; for (auto [it1, it2] : zip(vec1, vec2)) { // что-то делаем с итераторами и двигаемся по ним одновременно... }

у меня велосипед

я о такой фигне: vector vec1, vec2; for (auto [it1, it2] : zip(vec1, vec2)) { // что-то делаем с итераторами и двигаемся по ним одновременно... }

точнее два велосипеда, потому что там нельзя auto и auto& нормально сделать, потому что decltype(auto) it1

Я просто оставлю это здесь https://twitter.com/zygoloid/status/1044279153401389056 Вдруг среди обитателей этого чата найдутся любители отвратительного.

Я просто оставлю это здесь https://twitter.com/zygoloid/status/1044279153401389056 Вдруг среди обитателей этого чата найдутся любители отвратительного.

https://godbolt.org/z/1LHVm1 ( ͡° ͜ʖ ͡°) ( ͡☉ ͜ʖ ͡☉) ( ͡◉ ͜ʖ ͡◉)

https://godbolt.org/z/1LHVm1 ( ͡° ͜ʖ ͡°) ( ͡☉ ͜ʖ ͡☉) ( ͡◉ ͜ʖ ͡◉)

тут расширение гцц - то, что { blah; blah; value; } возвращает value. Но можно заменить лямбдой наверное

Ребят, подскажите, пожалуйста. auto sock = std::make_shared<boost::asio::ip::tcp::socket>( ioc, ep.protocol() ); sock-> async_connect( ep, [s= std::move(sock) ](auto && ...args){...} ); это undefined behaviour?

До C++17 это unspecified behavior, после - должно работать, т.к. добавили правило, что sock->async_connect будет вычислен до того, как будет вычислены аргументы (сделан move в lambda-capture-list). https://en.cppreference.com/w/cpp/language/eval_order "14) In a function-call expression, the expression that names the function is sequenced before every argument expression and every default argument."

До C++17 это unspecified behavior, после - должно работать, т.к. добавили правило, что sock->async_connect будет вычислен до того, как будет вычислены аргументы (сделан move в lambda-capture-list). https://en.cppreference.com/w/cpp/language/eval_order "14) In a function-call expression, the expression that names the function is sequenced before every argument expression and every default argument."

Большое спасибо. А то я уже на auto sock_raw = sock.get(); sock_raw->async_connect Чтобы наверняка было определено поведение.

До C++17 это unspecified behavior, после - должно работать, т.к. добавили правило, что sock->async_connect будет вычислен до того, как будет вычислены аргументы (сделан move в lambda-capture-list). https://en.cppreference.com/w/cpp/language/eval_order "14) In a function-call expression, the expression that names the function is sequenced before every argument expression and every default argument."

Код на c++17, так что можно по вашему совету написать.

Большое спасибо. А то я уже на auto sock_raw = sock.get(); sock_raw->async_connect Чтобы наверняка было определено поведение.

А есть причина мувать shared_ptr?

А есть причина мувать shared_ptr?

Атомарные счётчики - причина

Не платить за то что не используешь

Атомарные счётчики - причина

+1

Атомарные счётчики - причина

просто мне кажется, что стоимость async_connect должна быть настолько выше инкремента, что на это можно забить. С другой стороны, наличие вообще атомарности в счетчике у shared_ptr мне кажется весьма интересным. Есть ли вообще ситуации, когда это (на практике) полезно?

просто мне кажется, что стоимость async_connect должна быть настолько выше инкремента, что на это можно забить. С другой стороны, наличие вообще атомарности в счетчике у shared_ptr мне кажется весьма интересным. Есть ли вообще ситуации, когда это (на практике) полезно?

Инкремент то атомарный

просто мне кажется, что стоимость async_connect должна быть настолько выше инкремента, что на это можно забить. С другой стороны, наличие вообще атомарности в счетчике у shared_ptr мне кажется весьма интересным. Есть ли вообще ситуации, когда это (на практике) полезно?

В однопоточной программе shared_ptr имхо в 99% случаев можно заменить на uniq_ptr

В однопоточной программе shared_ptr имхо в 99% случаев можно заменить на uniq_ptr

Только не в 90% колбеков boost asio

просто мне кажется, что стоимость async_connect должна быть настолько выше инкремента, что на это можно забить. С другой стороны, наличие вообще атомарности в счетчике у shared_ptr мне кажется весьма интересным. Есть ли вообще ситуации, когда это (на практике) полезно?

shared_ptr разумно в многопоточных программах использовать

shared_ptr разумно в многопоточных программах использовать

И при использовании boost asio. Callback должен быть копируем в 90% случаев