Если вы считаете себя более умным и опытным человеком, чем все эти люди, придумывавшие математическую теорию, на её основе систему типов, потом поддержку в компиляторе и т.д., и считаете что они работали зря - то выкидывайте, конечно.
Просто интересно, с ASAN, UBSAN и т.д. вплоть до -Wall вы так же поступаете? Новомодные же игрушки, тоже код писать мешают.
А зачем для вывода одной строки вообще какое-то форматирование?
Есть такой IT-анекдот: один мальчик передавал строки в printf без форматирования и строчка с процентом внутри оторвала ему голову.
Вот ровно то же самое с любым форматным выводом: если возможно требовать, чтобы описание формата было всегда, то надо требовать. В противном случае получаса не пройдёт, как покатятся головы самых хитрых оптимизаторов.
Если вы хотите чего-то, что компилятор мешает вам сделать, то более чем в половине случаев вам надо перестать этого хотеть и изменить дизайн кода. Потому что вы хотите неправильного и компилятор мешает вам выстрелить себе в ногу.
Я это проходил, когда начинал писать на Haskell. Очень больно было, прям до слёз. Но потом стало гораздо легче даже в C++.
У Гугла огромная, гигантская, размером с небо и луну база кода на C++, с которой надо взаимодействовать и которую надо поддерживать. В Rust довольно неплохой interop с C/C++, но не без заковырок. Facebook потянул втащить Rust в свои инструменты и интегрировать с наиболее важными внутренними библиотеками, а Google решил что слишком рисковано, и придумал язык, у которого interop совсем тривиальный и "точно" ничего не поломает.
Это штука с очень ограниченной аудиторией: те, кому надо интегрироваться с огромным количеством старого C++ с минимальными усилиями, но новый код хочется писать на чём-то более безопасном.
Я хочу отметить, что с точки зрения "zero runtime", как его понимают студент и доцент, C++ попадает в одну кучу с Rust, особенно если не выключать exceptions.
Если для реализации своего избирательного права я должен встретиться с 6 рандомными людьми (в стране, через которую САМОЛЁТ ЛЕТИТ 10 ЧАСОВ) и СДАТЬ ИМ ОТПЕЧАТКИ ПАЛЬЦЕВ, то вам в Центризбирком надо с такими идеями. Такого прекрасного способа сделать голосование занятием для 2% самых элитных или неугомонных, у них ещё никто не придумал.
Ну как же. У нас будет оракул, который пример решение, выполнен договор на разработку сайта или нет, и если нет, то откатит платёжную транзакцию.
Ой, это придумали ещё в Древнем Египте и назвали "суд". Но мы ж не верим государству, мы верим третьим лицам, дорожащим репутацией. Пусть они разбирают, выполнен ли договор. Ой, это тоже придумано столетия назад и называется "арбитраж" (не путать с арбитражным судом в РФ).
Хорошо, тогда рассмотрим ситуацию со стороны разработчика. У нас будет тот же самый оракул, который наоборот, стриггерит платёжную транзакцию, когда договор признают выполненым. Заказчик не сможет кинуть на деньги! Ой, только если у него на кошельке будет достаточно средств. А мы их контрактом заблокируем! Ой, эту услугу банки тоже предоставляют уже давным-давно, только желающих блокировать оборотные средства пока каждый мелкий фрилансер сдаёт зачёты по алгебре не очень много...
В общем, становится понятно, зачем технарям в институтах курс по праву и по экономике. Чтобы новые восхитительные велосипеды были хоть как-то к реальности привязаны.
Более того, я немогу быть уверен, что завтра сервис с которым я взаимодействую не заблокирует мне аккаунт, не поменят формат выдачи, или не изменит логику без моего уведомления. Сравние это с криптой. Я изучаю исходный код сервиса на гитхабе, могу убедиться, что именно эти контракты задеплоены в сети, а значит исполняться будет именно то, что написано, а после и пишу код, который делает то, что мне нужно с финансами без единого обращения к гуманоидам.
А что именно мешает изменить API сервиса, который вы внимательно изучили на github?
Я в середине 200х был наблюдателем на выборах в Госдуму. Сначала председатель выгнал с участка члена комиссии с правом решающего голоса, которая ему мешала творить (это незаконно). Потом раскидали в десять рук бюллетени по стопочкам (это нарушение процедуры, плюс несколько раз ошиблись стопочкой). Потом посчитали одновременно стопочки поменьше (нарушение процедуры) и председатель заявил "ну а остальное за единую россию, значит" (вообще п-ц). Когда я возмутился, зам председателя отвёл меня в стороночку и сказал "ты от кого, от NNN? Давай им допишем полсотни голосов?"
Что им за всё это было? Ни-че-го.
Так что про "будет видно несоответствие" могу только процитировать анекдот "ути какие мы оптимисты".
В примере с UART - чаще, чем UART может выплюнуть байт. Или забить буфер, если он используется. Вычисляется делением :)
Корутины это по большому счёту сахарок для конечных автоматов: вместо того, чтобы фигачить состояния руками и городить колбэки для переключений, можно писать линейный код и поручить преобразование компилятору. Никакой магии там нет. Если сумеете написать hard realtime для ракеты в виде конечного автомата, то с корутинами будет то же самое, но не так мучительно.
"Традиционный" дизайн корутин (который я нагло списываю с folly) это отдельно executor, который занимается ожиданием событий, активацией корутин и т.д., фактически является рантаймом, и отдельно уже пользовательские корутины.
Синхронизация нужна между обработчиками прерываний и executor. Корутины про неё ничего знать не будут, им незачем: с обработчиком прерываний они напрямую не общаются. А если следить за тем, чтобы корутины достаточно часто отдавали управление, то для синхронизации между прерываниями и executor достаточно будет атомарных флагов, ну может для UART однобайтового буфера.
Между собой же корутины (пока исполняются в одном потоке) могут общаться практически как угодно. Примитивы типа очереди и mailbox делаются просто из стандартных контейнеров.
Это одна из прелестей корутин, из-за которых их активно используют даже в больших системах: если они все работают в одном потоке, то за исключением редких случаев синхронизация не нужна. Там даже прерываний не будет, потому что шедулер будет спать в epoll().
Недостатком является то, что если синхронизация нужна, то придётся переписывать примитивы: обычный mutex наверняка вызовет дедлок.
Представьте, что у вас есть десяток IO-bound задач и парочка CPU-bound и надо как-то всем этим жонглировать.
Если вы "возьмёте и посчитаете", то CPU-bound задачи будут работать по очереди, а IO-bound только если вы будете что-то делать в прерываниях (этот код довольно сложно корректно написать).
Если ваша ОС и железо поддерживают в каком-то виде многопоточность - можно запустить каждую задачу в своём потоке.
А если настоящей многопоточности нет, то можно использовать кооперативную многозадачность, для которой корутины НАКОНЕЦ-ТО предоставляют стандартизованную поддержку со стороны языка.
PGP это, по сути, способ передать один блоб между двумя абонентами, каждый из которых каким-то волшебным способом узнал ключ другого абонента: один чтобы зашифровать сообщение, другой чтобы проверить подпись. При этом в качестве транспорта используется ещё одна древность, в которой в те времена всё, вылезающее за пределы ASCII, могло быть при передаче испорчено. И по тем же историческим причинам вся информация о контексте сообщения, его месте в треде, да даже мета-информация типа заголовка и отправителя-получателя лежит в открытом виде.
Чтобы порекомендовать вам какой-то протокол надо для начала определиться, что вы вообще делаете и кем собираетесь стать: "почтой, мессенджером, чат-ботом, социальной сетью, безопасным файлообменником, криптовалютным платёжным сервисом и провайдером децентрализованных идентификаторов." У разных задач совершенно разные требования к безопасности и способы их реализации. Для безопасного файлообменника не стоит проблема "кто-то спустя месяц вставил пару сообщений в середину тредика" или "откуда я узнаю ключ этого чувака из солнечной Австралии", для чатика неактуально "как обеспечить произвольный доступ к середине тридцатигигабайтного файла, и хорошо если только на чтение".
Конкретно про PGP можно сказать, что если вам просто надо шифровать blob, без возможности редактирования, и ваша сеть позволяет передавать байты с любыми значениями, то возьмите libsodium и используйте оттуда crypto_box_easy. Не полная гарантия от выстрела в ногу, но авторы очень старались. И хотя бы в руках у вас будет не огнемёт.
Если вы считаете себя более умным и опытным человеком, чем все эти люди, придумывавшие математическую теорию, на её основе систему типов, потом поддержку в компиляторе и т.д., и считаете что они работали зря - то выкидывайте, конечно.
Просто интересно, с ASAN, UBSAN и т.д. вплоть до -Wall вы так же поступаете? Новомодные же игрушки, тоже код писать мешают.
Есть такой IT-анекдот: один мальчик передавал строки в printf без форматирования и строчка с процентом внутри оторвала ему голову.
Вот ровно то же самое с любым форматным выводом: если возможно требовать, чтобы описание формата было всегда, то надо требовать. В противном случае получаса не пройдёт, как покатятся головы самых хитрых оптимизаторов.
Если вы хотите чего-то, что компилятор мешает вам сделать, то более чем в половине случаев вам надо перестать этого хотеть и изменить дизайн кода. Потому что вы хотите неправильного и компилятор мешает вам выстрелить себе в ногу.
Я это проходил, когда начинал писать на Haskell. Очень больно было, прям до слёз. Но потом стало гораздо легче даже в C++.
У Гугла огромная, гигантская, размером с небо и луну база кода на C++, с которой надо взаимодействовать и которую надо поддерживать. В Rust довольно неплохой interop с C/C++, но не без заковырок. Facebook потянул втащить Rust в свои инструменты и интегрировать с наиболее важными внутренними библиотеками, а Google решил что слишком рисковано, и придумал язык, у которого interop совсем тривиальный и "точно" ничего не поломает.
Это штука с очень ограниченной аудиторией: те, кому надо интегрироваться с огромным количеством старого C++ с минимальными усилиями, но новый код хочется писать на чём-то более безопасном.
Я хочу отметить, что с точки зрения "zero runtime", как его понимают студент и доцент, C++ попадает в одну кучу с Rust, особенно если не выключать exceptions.
Если для реализации своего избирательного права я должен встретиться с 6 рандомными людьми (в стране, через которую САМОЛЁТ ЛЕТИТ 10 ЧАСОВ) и СДАТЬ ИМ ОТПЕЧАТКИ ПАЛЬЦЕВ, то вам в Центризбирком надо с такими идеями. Такого прекрасного способа сделать голосование занятием для 2% самых элитных или неугомонных, у них ещё никто не придумал.
Ну как же. У нас будет оракул, который пример решение, выполнен договор на разработку сайта или нет, и если нет, то откатит платёжную транзакцию.
Ой, это придумали ещё в Древнем Египте и назвали "суд". Но мы ж не верим государству, мы верим третьим лицам, дорожащим репутацией. Пусть они разбирают, выполнен ли договор. Ой, это тоже придумано столетия назад и называется "арбитраж" (не путать с арбитражным судом в РФ).
Хорошо, тогда рассмотрим ситуацию со стороны разработчика. У нас будет тот же самый оракул, который наоборот, стриггерит платёжную транзакцию, когда договор признают выполненым. Заказчик не сможет кинуть на деньги! Ой, только если у него на кошельке будет достаточно средств. А мы их контрактом заблокируем! Ой, эту услугу банки тоже предоставляют уже давным-давно, только желающих блокировать оборотные средства пока каждый мелкий фрилансер сдаёт зачёты по алгебре не очень много...
В общем, становится понятно, зачем технарям в институтах курс по праву и по экономике. Чтобы новые восхитительные велосипеды были хоть как-то к реальности привязаны.
А что именно мешает изменить API сервиса, который вы внимательно изучили на github?
Я в середине 200х был наблюдателем на выборах в Госдуму. Сначала председатель выгнал с участка члена комиссии с правом решающего голоса, которая ему мешала творить (это незаконно). Потом раскидали в десять рук бюллетени по стопочкам (это нарушение процедуры, плюс несколько раз ошиблись стопочкой). Потом посчитали одновременно стопочки поменьше (нарушение процедуры) и председатель заявил "ну а остальное за единую россию, значит" (вообще п-ц). Когда я возмутился, зам председателя отвёл меня в стороночку и сказал "ты от кого, от NNN? Давай им допишем полсотни голосов?"
Что им за всё это было? Ни-че-го.
Так что про "будет видно несоответствие" могу только процитировать анекдот "ути какие мы оптимисты".
В примере с UART - чаще, чем UART может выплюнуть байт. Или забить буфер, если он используется. Вычисляется делением :)
Корутины это по большому счёту сахарок для конечных автоматов: вместо того, чтобы фигачить состояния руками и городить колбэки для переключений, можно писать линейный код и поручить преобразование компилятору. Никакой магии там нет. Если сумеете написать hard realtime для ракеты в виде конечного автомата, то с корутинами будет то же самое, но не так мучительно.
"Традиционный" дизайн корутин (который я нагло списываю с folly) это отдельно executor, который занимается ожиданием событий, активацией корутин и т.д., фактически является рантаймом, и отдельно уже пользовательские корутины.
Синхронизация нужна между обработчиками прерываний и executor. Корутины про неё ничего знать не будут, им незачем: с обработчиком прерываний они напрямую не общаются. А если следить за тем, чтобы корутины достаточно часто отдавали управление, то для синхронизации между прерываниями и executor достаточно будет атомарных флагов, ну может для UART однобайтового буфера.
Между собой же корутины (пока исполняются в одном потоке) могут общаться практически как угодно. Примитивы типа очереди и mailbox делаются просто из стандартных контейнеров.
Спасибо, именно такого базового примера мне не хватало.
Это одна из прелестей корутин, из-за которых их активно используют даже в больших системах: если они все работают в одном потоке, то за исключением редких случаев синхронизация не нужна. Там даже прерываний не будет, потому что шедулер будет спать в epoll().
Недостатком является то, что если синхронизация нужна, то придётся переписывать примитивы: обычный mutex наверняка вызовет дедлок.
Представьте, что у вас есть десяток IO-bound задач и парочка CPU-bound и надо как-то всем этим жонглировать.
Если вы "возьмёте и посчитаете", то CPU-bound задачи будут работать по очереди, а IO-bound только если вы будете что-то делать в прерываниях (этот код довольно сложно корректно написать).
Если ваша ОС и железо поддерживают в каком-то виде многопоточность - можно запустить каждую задачу в своём потоке.
А если настоящей многопоточности нет, то можно использовать кооперативную многозадачность, для которой корутины НАКОНЕЦ-ТО предоставляют стандартизованную поддержку со стороны языка.
PGP это, по сути, способ передать один блоб между двумя абонентами, каждый из которых каким-то волшебным способом узнал ключ другого абонента: один чтобы зашифровать сообщение, другой чтобы проверить подпись. При этом в качестве транспорта используется ещё одна древность, в которой в те времена всё, вылезающее за пределы ASCII, могло быть при передаче испорчено. И по тем же историческим причинам вся информация о контексте сообщения, его месте в треде, да даже мета-информация типа заголовка и отправителя-получателя лежит в открытом виде.
Чтобы порекомендовать вам какой-то протокол надо для начала определиться, что вы вообще делаете и кем собираетесь стать: "почтой, мессенджером, чат-ботом, социальной сетью, безопасным файлообменником, криптовалютным платёжным сервисом и провайдером децентрализованных идентификаторов." У разных задач совершенно разные требования к безопасности и способы их реализации. Для безопасного файлообменника не стоит проблема "кто-то спустя месяц вставил пару сообщений в середину тредика" или "откуда я узнаю ключ этого чувака из солнечной Австралии", для чатика неактуально "как обеспечить произвольный доступ к середине тридцатигигабайтного файла, и хорошо если только на чтение".
Конкретно про PGP можно сказать, что если вам просто надо шифровать blob, без возможности редактирования, и ваша сеть позволяет передавать байты с любыми значениями, то возьмите libsodium и используйте оттуда crypto_box_easy. Не полная гарантия от выстрела в ногу, но авторы очень старались. И хотя бы в руках у вас будет не огнемёт.
Зачем в 2022 году использовать PGP? Это же технология тридцатилетней давности, криптография с тех пор ушла далеко вперёд.
Ranges очень легко понять, если какое-то время поковырять операции над списками в Haskell, особенно в point-free нотации :)
Вы бы хоть
uint32_tиuint8_tнаписали, что ли...Design pattern это библиотека, которую невозможно написать, потому что язык не позволяет (c) не_мой
Это проблема не перевода, а оригинала. Автор оригинала явно использует atomic как синоним lock-free, и это достаточно популярное толкование.