Потому что соответственно к Networking Proposal

#include <type_traits> namespace foo { template<typename T> struct Foo { template<typename... Args> Foo(Args&&...) { } }; template<typename T, typename... Ts> Foo(T&&, Ts&&...) -> Foo<std::remove_reference_t<T>>; } int main() { using namespace foo; Foo{1, 2, 3, 4}; }

такое ощущение что он deduction guides не понмиает

Ну, т.е. не гарантируется, что во время.

Похоже, что действительно хендлеры вызываются после вызова cancel().

http://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/reference/async_read_until/overload5.html Вот нашел тёмный угол на мой вкус. Утверждается, что A streambuf object into which the data will be read. Ownership of the streambuf is retained by the caller, which must guarantee that it remains valid until the handler is called. Вполне законное требование, учитывая, что функция принимает ссылку на объект, которой затем пользуется в неясный момент времени. Но на мой вкус тут логичнее было бы гарантировать until the handler is called or operation is cancelled. Потому-что мы поняли, что эти две ситуации не всегда совпадают во времени, а после отмены операции ей уж точно не нужны ресурсы. И вот неясно, это небрежность в документации или какие-то темные углы реализации которые я не улавливаю.

Сначала я инициирую отмену операции, а затем спустя какое-то время вызывается хендлер. Память хендлера никуда не денется, он отдается внутрь копированием/перемещением. Речь идет сейчас про буфер, который отдается по ссылке. На мой взгляд, меня заставляют гарантировать его сохранность в тонкий промежуток времени между тем как я отменил операцию (а гарантируется, что операция будет immediately cancelled) и тем, как вызвался хендлер (в соответствии с exactly one time).

потому что пока ты ожидаешь отмены, операция ОС может выполниться и записать в буфер что-то. Приходящие из ОС события ты никак не контролируешь, если освободишь память - перезапишется что-то еще.

Что значит "ожидаешь"? Я конечно не претендую на то, чтобы быть носителем английского, но operations to finish immediately (как сказано в документации) означает что операция будет отменена немедленно, если бы надо было чего-то ожидать, то было бы сказано operations to finish eventually. ОС тут не причем, по той простой причине, что есть разница между получением события "доступны данные" и его обработкой, т.е. актуальным чтением (когда нужен буфер И после которого планируется выполнение хендлера). Между ними нужно еще отобразить файловый дескриптор ОС во внутреннюю структуру бустов, чтобы понять, что чтение вообще заказывали. Так как действует правило одного вызова хендлера, значит boost asio при вызове отмены операции способен различить две ситуации: 1) отмена вызвана до непосредственной обработки операции 2) отмена вызвана после непосредственной обработки и вызов хендлера уже запланирован. Во втором случае, очевидно, ссылка на буфер уже не нужна кишкам asio (будем считать, что мы туда не ходим из хендлера).. В первом случае, нет никакой проблемы атомарно выкинуть запрошенную операцию из списка и таким образом отменить реальное чтение данных..

зацените 3дпати

типично для С++

да, что ж поделать, что люди не переделали ещё на пакетный менеджер какой-нибудь

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

Короче, я смотрю реализацию impl/select_reactor.ipp и там всё как я сказал - операции хранятся в очереди, все обращения к которой защищены мьютексом, а операция просто cancel_ops удаляет из очередей релевантные операции. Так что операция из очереди в любом случае атомарно пропадет, либо во время cancel_ops(), либо после вызова select() внутри run(), когда произойдет релевантное событие в ОС.

ну да, select() много в буфера записывает....

Если будет операция в очереди, то ::read() запишет в буфер и выкинет операцию из очереди. А если не будет в очереди (отмена сработала раньше, чем `select()`), то и не будет.записывать.

Вместе они случится не могут, они оба защищены одним мьютексом. Если отмена срабатывает после read(), тогда она просто ничего не делает. Операция уже была обработана, и всё, что от неё осталось, это хендлер, который ожидает в очереди на запуск и будет когда-нибудь потом запущен.

но если отмена сработала в тот момент когда случился read() тут тебе и пригодилась гарантия лайфтайма буфера

я свою дозу фиксов за аналогичными матвеями не врубающимися в асинхронные евенты от ОС уже получил, спасибо

а что там, ~buffer_owner() { if (has_pending_io()) discard_pending_io(); } ?

я тут выяснил, что при наличии бинарной совместимости, polymorphic allocator позволяет не отстреливать себе ноги при передаче контейнеров в dll, например

а зачем вообще ставить не /MD[d] ?

иногда статически линкуют из-за версионирования

а зачем вообще ставить не /MD[d] ?

периодически нужно компилять под win xp какой-нибудь

а с новой CRT оно не работает )

а зачем вообще ставить не /MD[d] ?

это как вообще?