Его везде гнобят мол слишком медленный

медленный для чего?

мол никто не использует в настоящем продакшене

Если не буст асио, то что юзать?

Его везде гнобят мол слишком медленный

При не кривых руках, растущих из правильных мест - он нисколько не медленный.

мол никто не использует в настоящем продакшене

В Яндексе в продакшене его юзают\юзали.

мол никто не использует в настоящем продакшене

Много раз видел в продакшене на high load. Никто не жаловался

ну ладненько

спасибо

Весь код Си компилируется без изменений c++ компилятором.

Нет. C++ не надмножество си, в отличии к примеру от obj c. Традиционное int main(){ main(); }

Ку

Ништяк! https://blog.tartanllama.xyz/c++/2017/05/19/sycl/

У меня есть указатель на переменную типа unsigned long, мне нужно получить каждую цифру. Как так сделать?

#supapro

Ништяк! https://blog.tartanllama.xyz/c++/2017/05/19/sycl/

круто!

https://www.facebook.com/sloneus/posts/802806086537556

https://www.facebook.com/sloneus/posts/802806086537556

Разберём каждый из плюсов С, найденных автором: 1) "экономит невероятное количество времени и сил" - использовать нативное АПИ скоетов - жуть адская... А , он использовал libev! Удачи с поиском незакрытых дескрипторов и утечками памяти. Мне лично без деструкторов жить страшно, а отлаживаться - долго. 2) "я точно знаю сколько было выделений памяти и что куда копировалось". Хм, с ASIO я это тоже знаю. ЧЯДНТ? 3) "пользоваться валгриндом/гдб стало проще на порядок". Пользоваться этими инструментами для отладки асинхронного кода - нулевое удоволствие вне зависимости от языка. 4.0) "упростился рефакторинг" - рефакторить всегда просто, когда рефакторишь свой код. Заставьте рефакторить чужой С код любого разработчика - услышите много новых ругательств, про утечки памяти и незакрытые дескрипторы. 4.1) "зависимостей остались только libc, libssl/libcrypto и libev". Используйте ASIO (без Boost) и C++11, получите такое же количество зависимостей. Ставлю под сомнение профессионализм автора поста: нет ни кода "до", ни кода "после". Просто голословные завления.

При не кривых руках, растущих из правильных мест - он нисколько не медленный.

Однако он будет медленее чем асинхронщина на корутинах.

И в плане написания кода, тоже минусы, связанные с тем, что надо разрывать код на вызовы асио. В итоге те несколько раз, что я сталкивался с асио выглядели как стейт машина + асио. В этом плане в корутинах всё несколько понагляднее.

Однако он будет медленее чем асинхронщина на корутинах.

Почему?

Почему?

Корутинные контексты переключаются в юзерспейсе за десятки наносекунд.

Треды переключаются за микросекунды.

Сама по себе callback-ная схема предполагает расходы на вызовы функций.

Корутинные контексты переключаются в юзерспейсе за десятки наносекунд.

Корутины не уберут переключения ОС потоков, а лишь *добавят* еще переключения контекста корутин. От callback вы не убежите (по крайней мере пока Windows не протянет корутины пространства ядра в userspace, но этого ждать ещё ооочень долго и неизвестно получится ли в принципе)

Корутины - сахар, а не способ ускорить программу

Или я чего-то не понимаю, или виндовые файберы уже живут в userspace. Но как бы там ни было, когда у меня была задача сделать корутины в проекте, еще до выступлений Гора на эту тему, я просто написал десяток ассемблерных инструкций по сохранению и установке контекста.

И в плане написания кода, тоже минусы, связанные с тем, что надо разрывать код на вызовы асио. В итоге те несколько раз, что я сталкивался с асио выглядели как стейт машина + асио. В этом плане в корутинах всё несколько понагляднее.

ну так асио со стейт машиной используется, логично, можно сделать по идее асио с корутинами...

Сделано.

так, а ссылка

Корутины не уберут переключения ОС потоков, а лишь *добавят* еще переключения контекста корутин. От callback вы не убежите (по крайней мере пока Windows не протянет корутины пространства ядра в userspace, но этого ждать ещё ооочень долго и неизвестно получится ли в принципе)

Речь идёт о том, что от программиста спрятаны все кишки диспетчеризации. Можно сделать однопоточное приложение при этом имея на каждое соединение отдельный контекст выполнения, который еще и выглядит как синхронный.

Любое другое однопоточное решение, конечно будет делать то же самое, но надо будет явно ходить в epoll\kqueue и восстанавливать какой-то стейт.

Сделано.

а ссылка?

а ссылка?

С этим сложно. Legal issues.

ну то есть бесполезно, когда будет в OSS - приходите еще

у вас там boost::coroutine(2) или что-то свое?

у вас там boost::coroutine(2) или что-то свое?

Вообще зависимостей от 3rd party нет. При этом кроссплатформа на win\linux\osx

понял, даже видеть это не хочу

А зря.

поверь мне, не зря

Даже спорить не буду. Уровень конструктивности около 0.

Legal issues, т.е. патентами обмазано?

Любое другое однопоточное решение, конечно будет делать то же самое, но надо будет явно ходить в epoll\kqueue и восстанавливать какой-то стейт.

Если стейт достаточно большой, то может быть дешевле переключить esp и eip, чем читать его из какой-то структуры.

Даже спорить не буду. Уровень конструктивности около 0.

да и не о чем - никем не протестированные кастомные корутины с кривой билдсистемой и закрытым кодом - нафиг сразу

да и не о чем - никем не протестированные кастомные корутины с кривой билдсистемой и закрытым кодом - нафиг сразу

Чини экстрасенсорику! Покрытие юнит-тестами почти 100%, собирается cmake-ом.

Скоро откроем.

Не в тему текущего спора: тут кидали обёртку над OpenCV, а есть ещё варианты?

С подписью zero-overhead, very simple желательно

И header-only)

и mit license

Любое другое однопоточное решение, конечно будет делать то же самое, но надо будет явно ходить в epoll\kqueue и восстанавливать какой-то стейт.

Так в том то и проблема: epoll\kqueue\iocp не умеют работать напрямую с корутинами, вам придется в любом случае восстанавливать стейт корутины ручками после epoll\kqueue\iocp

И header-only)

Ну это уже идеал, либу я не поленюсь сбилдить

Так в том то и проблема: epoll\kqueue\iocp не умеют работать напрямую с корутинами, вам придется в любом случае восстанавливать стейт корутины ручками после epoll\kqueue\iocp

Конечно, мы так и делаем, я ответил на это вот здесь:

Если стейт достаточно большой, то может быть дешевле переключить esp и eip, чем читать его из какой-то структуры.

Скоро откроем.

ВОТ ТАК ТО ЛУЧШЕ

Если стейт достаточно большой, то может быть дешевле переключить esp и eip, чем читать его из какой-то структуры.

А в чем разница? Вроде прочитать указатель из epoll или восстановить указатель для esp - приблизительно одно и то же?

Да, приблизительно одно и то же. Но для пользователя это выглядит совсем по-другому.

Не в тему текущего спора: тут кидали обёртку над OpenCV, а есть ещё варианты?

Даже не так. Просто для GPU вычислений

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

В случае если нам возвращается указатель на какой-то стейт более менее сложная программа уже должна будет делать еще какую-то работу, чтобы прийти в место продолжения бизнес-логики.

поверь мне, не зря

Андрей, мне казалось, что ты достаточно логичен, чтобы переставать вести дискуссию с людьми, которые не могут это делать конструктивно :)

Вот это вот "не знаю, но осуждаю" - это круто!

Андрей, мне казалось, что ты достаточно логичен, чтобы переставать вести дискуссию с людьми, которые не могут это делать конструктивно :)

Есть вещи, которыми я горжусь, и даже со своей разумностью бывает сложно не «стригерриться».

По факту, на данный момент это лучшее решение для диспетчеризации задач под Linux, OSX и Windows.

В случае если нам возвращается указатель на какой-то стейт более менее сложная программа уже должна будет делать еще какую-то работу, чтобы прийти в место продолжения бизнес-логики.

А теперь выскажу возможно спекулятивную мысль, что восстановление контекста в том месте где он прервался по коду имеет лучшие показатели по попаданию в кеш инструкций, чем ручное восстановление стейта по указателю, который вернулся из epoll/.../..., и переход к нужной ветке бизнес-логики. Это заявление я не проверял, но такое подозрение есть.

А теперь выскажу возможно спекулятивную мысль, что восстановление контекста в том месте где он прервался по коду имеет лучшие показатели по попаданию в кеш инструкций, чем ручное восстановление стейта по указателю, который вернулся из epoll/.../..., и переход к нужной ветке бизнес-логики. Это заявление я не проверял, но такое подозрение есть.

Я проверял. Быстрее.

По факту, на данный момент это лучшее решение для диспетчеризации задач под Linux, OSX и Windows.

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

Всем привет! Cocos2d-x разработчики есть? Почему остановились на кокосе, какие альтернативы рассматривали?

привет. насколько знаю с кокосом всё сложно

альтернатив особо нет

при разработке вылазиет много ньюансов

Unity, defold и т.д.

под дроиды производительность нужна

да, это верно

в таком случае лучше либгдх брать

из него со спайном работать приятнее, чем из кокоса

Всем привет! Cocos2d-x разработчики есть? Почему остановились на кокосе, какие альтернативы рассматривали?

А что именно от кокоса надо? Почему бы не использовать связку в духе sfml + box2d ?

Изучаю технологический рынок для нового проекта.

Плюс у нас есть другой проект на кокосе. Разраб всем доволен, но хочется альтернативных мнений.

+, горит

Шо за вундервуд? Это типа александреску для тех кому не хватило первой дозы?

Тут в чате есть эта книга