# Текстовая трансляция CppCast 276: Networking TS

Эпизод 276 CppCast, беседа с Робертом Лихи, 2 декабря 2020 года\.

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

![0795_Podcast_Networking_TS_ru/image1.png](https://import.viva64.com/docx/blog/0795_Podcast_Networking_TS_ru/image1.png)

Сегодняшний подкаст посвящен С\+\+\. Поговорим о возможностях использования нового кроссплатформенного фреймворка C\+\+ Plywood для создания игр на C\+\+, шокируем читателей "страшной" блок\-схемой инициализации C\+\+20, обсудим точность использования исключений на современных 64\-битных ПК\-архитектурах, а также внедрение экзекьюторов в стандартизацию Networking TS\.

Ссылка на оригинал подкаста будет в конце статьи\.

**Примечание\. **_Текст подкаста был отредактирован с целью скорректировать неточности в речи\. Он скорее отражает смысл высказываний, а не дословные утверждения спикеров\._

Итак, начнем\.

![0795_Podcast_Networking_TS_ru/image2.png](https://import.viva64.com/docx/blog/0795_Podcast_Networking_TS_ru/image2.png)

Гость данного эпизода – Роберт Лихи, выпускник Университета Виктории, где он изучал компьютерную графику, теорию игр и цифровую обработку изображений\. Четыре с половиной года проработав фулл\-стек веб\-разработчиком, в начале 2017 года он сменил сферу деятельности, приступив к изучению финансовых технологий\. Являясь членом комитета ISO C\+\+, он выступает за высококачественное и процессно\-ориентированное программное обеспечение, соответствующее строгим стандартам эффективности, которыми так славится финансовая сфера\.

## Игра с открытым свободным кодом Flappy Hero

![0795_Podcast_Networking_TS_ru/image3.png](https://import.viva64.com/docx/blog/0795_Podcast_Networking_TS_ru/image3.png)

**Примечание\. **_Ранее Джефф Прешинг, автор статьи "[Игра с открытым свободным кодом Flappy Hero](https://preshing.com/20201126/a-small-open-source-game-in-cpp/)" выложил пост "[Как написать кастомный игровой движок на C\+\+](https://preshing.com/20171218/how-to-write-your-own-cpp-game-engine/)", где описывает процесс создания собственной игры на C\+\+\._

_В статье "[Новый кроссплатформенный фреймворк C\+\+ Plywood с открытым исходным кодом](https://preshing.com/20200526/a-new-cross-platform-open-source-cpp-framework/)" автор отмечает, что [фреймворк Plywood](https://github.com/arc80/plywood) – не игровой движок, а фреймворк для создания любого программного обеспечения на C\+\+\. [Документация Plywood](https://plywood.arc80.com/) создается с помощью синтаксического анализатора C\+\+, форматируется с помощью анализатора Markdown и запускается на настраиваемом веб\-сервере, написанном с использованием Plywood\. Интеграция сторонних библиотек в C\+\+ может стать проблемой, но Plywood стремится упростить данный процесс\._

_Роб_ _Ирвинг_: Итак, начнем с простой игры с открытым исходным кодом на C\+\+ на preshing\.com\. Очень похоже на рекламу Plywood, фреймворка C\+\+, на котором автор написал игру\. Демо\-игра Flappy Hero является клоном известной игры [Flappy Bird](https://ru.wikipedia.org/wiki/Flappy_Bird), которая произвела фурор в начале 2010\-х годов\.

_Джейсон Тернер_: Парень, который создал Flappy Bird, так расстроился из\-за всей этой известности, что залег на дно и удалил игру из App Store\.

_Роб Ирвинг_: Он утверждает, что удалил ее только потому, что люди стали одержимы этой игрой\. Он хотел, чтобы эта игра просто помогала отвлечься на несколько минут, но люди стали зависимы от нее\.

_Роберт Лихи_: Эта игра стала таким же феноменом в мобильной индустрии, как в свое время стала Sega Genesis\. Сейчас в метро каждый второй играет во что\-то на телефоне, а до появления Flappy Bird и всего этого, люди читали книги или просто сидели, слушая музыку или что\-то в этом роде\.

_Роб Ирвинг_: Простая игра, от которой невозможно оторваться\. Играя в нее, можно запросто потеряться\.

_Роберт Лихи_: Я ознакомился с фреймворком Plywood\. Интересно, что, похоже, он позволяет объявлять и создавать модули в самом C\+\+\. Пишешь небольшую функцию, которая принимает параметр, а затем создаешь свой модуль\. Я даже не знал, что так можно на C\+\+\.

_Роб Ирвинг_: Эти модули чем\-то похожи на модули C\+\+20?

_Роберт Лихи_: Согласно информации на сайте, [модули Plywood](https://plywood.arc80.com/docs/KeyConcepts) не следует путать с модулями C\+\+20\.

Перейдем к следующей теме\.

## Блок\-схема инициализации C\+\+20

![0795_Podcast_Networking_TS_ru/image4.png](https://import.viva64.com/docx/blog/0795_Podcast_Networking_TS_ru/image4.png)

_Роб Ирвинг_: Теперь обсудим [пост из C\+\+\-сабреддита](https://old.reddit.com/r/cpp/comments/k2cozv/the_c_20_initialization_flowchart/), а конкретно блок\-схему инициализации C\+\+20\. Огромную блок\-схему, на которую просто страшно смотреть и осознавать, что инициализация все еще так сложна\.

_Джейсон Тернер_: Все еще? Она даже сложнее последнего C\+\+\.

_Роб Ирвинг_: И становится еще сложнее\. Это правда\.

_Роберт Лихи_: Сейчас в комитете стандартизации обсуждают следующее\. Если кто\-то опубликует предложение в стандарт, которое каким\-либо образом упростит язык, все удивятся, как до такого вообще можно было додуматься\. Так вот, с инициализацией точно так же\. После каждого релиза или во время совещания кто\-нибудь обязательно начнет обсуждать отдельные особые случаи: "Вот сейчас оно не работает\. Давайте добавим еще пару ветвлений на эту блок\-схему, чтобы все заработало\. Как думаете, стоит?"\. PNG\-картинка уже настолько большая, что всякий раз, когда я переключаюсь обратно на вкладку, уходит несколько секунд, чтобы она прогрузилась\.

_Джейсон Тернер_: Чувствую я, что некоторые из этих граничных случаев, попавших в блок\-схему, являются "мифическими существами", обнаруженными при написании компиляторов во время поиска новых краевых случаев\.

_Роберт Лихи_: Любопытно, как это вообще происходит в программной инженерии\. Вроде, все учел и продумал, а приступив к реализации, понял, что ничего не работает\. Поэтому я не могу понять, радует или обескураживает то, что такое происходит в комитете\. Даже если собрать лучшие умы C\+\+ в одной комнате, они все равно не смогут заменить одного парня, пытающегося провести реализацию компилятора\.

_Джейсон Тернер_: Забавно, хотя автор утверждает, что потратил на это гораздо меньше времени, чем ожидал\. Прочитав это перед тем, как кликнуть, я ожидал увидеть относительно небольшую блок\-схему\. А потом я понял, что придется приближать изображение и крутить вниз, чтобы просмотреть\. Если только у вас нет 48\-дюймового монитора или чего\-то похожего\.

_Роберт Лихи_: У меня есть 49\-дюймовый монитор, который все равно не подходит\. Точнее подходит, но прочитать ничего не получится\. Все равно придется увеличить масштаб\.

_Джейсон Тернер_: Нужно использовать 8K 49\-дюймовый монитор, очень близко придвинуться к монитору и только тогда получится это прочитать\.

## C\+\+\-исключения на современных 64\-битных ПК\-архитектурах

_Роб Ирвинг_: Следующая новость – это пост в блоге lordsoftech\.com, под названием: "Коды ошибок гораздо медленнее, чем исключения"\. Речь идет о том, что с современными 64\-битными архитектурами проблемы ухудшения производительности не должны стать причиной избегания исключений\. Тестирования производили с помощью средств синтаксического анализа XML, первый раз реализовали с ошибками в коде, второй – с исключениями\. В итоге обнаружили, что код с ошибкой, использующий имплементацию, замедляет работу программы примерно на 6%\.

**Примечание\. **_Полный исходный код можете найти [здесь](https://gist.github.com/Dugy/2532c810bb232b8ff1603cfa679bdf28)\._

_Джейсон_ _Тернер_: Соглашусь, но во вложенных кейсах, именно эти коды ошибок будут медленнее, чем исключения, при условии, что исключения действительно исключительны\. Я провел собственное исследование по этому вопросу и не совсем согласен с приведенными здесь примерами, потому что автор переключился с API, возвращающего значение, на API, принимающий значение по ссылке\. А если бы он вместо этого использовал expected со значением плюс код ошибки в качестве возвращаемого значения, то я думаю, получились бы немного другие значения\.

_Роб Ирвинг:_ Можно было провести третью пробную реализацию\. Сначала реализовать коды ошибок, затем исключения, а потом с expected\.

_Роберт Лихи:_ Думаю, что [предложение expected](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0323r7.html) сейчас находится как бы в чистилище комитета по стандартам\. Но, благодаря Найлу Дугласу, можно скачать и использовать Boost\.Outcome\. Правда я почти уверен, что, проходя экспертную оценку в Boost, ему пришлось удалить монадические интерфейсы\. Ближе к концу статьи приведен пример упрощения кода с использованием исключений, а в качестве запасного варианта используется макрос PROPAGATE\_ERROR\.

Я как\-то работал с версией expected с монадическим интерфейсом\. Отличный способ работы с кодами ошибок\. Boilerplate не было, по\-моему, тогда это называлось присваиванием значения\. На выходе получаем итоговое значение или найденную ошибку\. Однако в данной реализации, как и в случае с синтаксическим анализатором XML, генерирующим исключения для плохо сформированного XML, возникают вопросы, не раз обсуждавшиеся в исследовательской группе Networking\. Что подразумевается под ошибкой? Чья это ошибка? Редко в файл попадает ошибка? Этот XML исключительный? Читаем случайные файлы и пытаемся выяснить, есть ли в них XML, или получаем входные данные, которые принимаем за XML? Какая ситуация исключительная?

Поскольку ответить на эти вопросы непросто, нужно установить таксономию ошибок, которая сама по себе усложняется\. Напоминает ошибку bad\_alloc\. Правда некоторые искренне верят, что bad\_alloc не может произойти\. А если и происходит, при работе в Linux, она настигнет тебя, а если нет, не получится ничего восстановить, придется преждевременно завершить работу\.

_Роберт Лихи_: Интересно то, что, даже зная в какой области находишься, невозможно понять, что действительно исключительно, потому что кто\-то может попытаться использовать вашу XML\-библиотеку, чтобы выяснить, является ли эта строка XML случайной\. Здесь дело не в том, что XML неисключительный, а в том, что это только часть возможного развития событий\.

_Джейсон Тернер_: Интересная мысль\. Всякий раз, когда студенты спрашивают меня о сравнении кодов ошибок с исключениями или о чем\-то еще, я обязательно отмечаю, что главное – быть последовательными в своей кодовой базе\. Ненавижу, когда я перехожу к базе кода и не знаю, чего ожидать\. Неважно, сигнализируешь ли об ошибке, возвращая "true", возвращая "false" или вообще используя исключения\. Главное, чтобы используемые методы согласовывались друг с другом во всем коде_\._

_Роберт Лихи_: Насколько я помню, в POSIX при успешном завершении программы возвращают "false"\-значения \(нулевые значения\), а в Windows все наоборот\. В итоге, во время программирования на кроссплатформенной операционной системе, однажды точно ошибешься при проверке своей базы кода\.

## Ушел из жизни Биман Доус

![0795_Podcast_Networking_TS_ru/image5.png](https://import.viva64.com/docx/blog/0795_Podcast_Networking_TS_ru/image5.png)

**Примечание\. **_Биман Доус был одним из самых влиятельных людей в истории C\+\+\. Комитет и сообщества программистов C\+\+ во многом обязаны Биману\. Он входил в состав комитета по стандартам C\+\+ \(WG21\) с 1992 года и возглавлял рабочую группу библиотеки в течение пяти лет в ходе утверждения первого стандарта C\+\+, C\+\+ 98\. Биман Доус был разработчиком [<filesystem\>](https://github.com/Beman/filesystem-proposal), входящую в стандарт\._

_Роб Ирвинг_: Недавно до нас дошло печальное известие, ушел из жизни [Биман Доус](https://old.reddit.com/r/cpp/comments/k58a2u/beman_dawes_has_passed_away_boost_filesystem_wg21/), автор [Boost and File System](https://www.boost.org/doc/libs/1_75_0/libs/filesystem/doc/index.htm), член комитета ISO\. Он привнес много нового в язык C\+\+\. Выражаем соболезнования его семье\. Мы пытались связаться с ним и пригласить его на шоу около двух лет назад, но встреча не состоялась\.

_Роберт Лихи_: Мне сообщили об этом за 30 минут до шоу, всегда неприятно получать такие новости\.

## Networking TS с нуля: объекты ввода\-вывода – Роберт Лихи – CppCon 2020

_Роб Ирвинг_: Роберт, расскажи нам немного о Networking TS\. Как это будет выглядеть в C\+\+23?

_Роберт Лихи_: В комитете хотят по\-прежнему использовать экзекьюторы и Networking в C\+\+23\. Бесспорно, вся эта история с COVID внесла коррективы в наши планы\. Сейчас у 4\-й Исследовательской группы много долгосрочных задач и исследований\. Чтобы сократить время интеграции с экзекьюторами, некоторые используют Asio, своего рода эталонную реализацию\.

Мы надеемся, что экзекьюторы в будущем будут похожи на Asio, но на данный момент TS отстает от них\. Чтобы объединить их, потребуется провести много исследований\. На каждых переговорах 4\-ой Исследовательской группы речь шла об этом\. Пока в Networking не завершится работа с экзекьюторами, все переговоры носят предварительный характер\.

![0795_Podcast_Networking_TS_ru/image6.png](https://import.viva64.com/docx/blog/0795_Podcast_Networking_TS_ru/image6.png)

Мы, вроде, и уверены, как это будет выглядеть в C\+\+23, но вполне возможно, что в последнюю минуту, все неожиданно изменится, и все усилия окажутся напрасны\. Это уже не раз обсуждалось в Networking TS\.

_Роб Ирвинг_: Как именно связаны экзекьюторы и предложение Networking?

_Роберт_ _Лихи_**:** Думаю, это зависит от уровня, на котором пишется сетевой код\. Если код запускается методом бутстрэппинга, экзекьютор, по сути, является способом получить этот фоновый контекст для выполнения работы\. Одна из основных проблем асинхронного программирования заключается в том, что при написании синхронного кода, есть контекст выполнения\. Начинаешь с main или с некого потока\. То есть, есть ЦП, команда выполняется, можно войти в функцию и остаться там, а затем вернуться, и еще остается место для выполнения кода\.

При выполнении асинхронного кода все это происходит в фоновом режиме и возникает вопрос: откуда берется контекст для запуска кода? Связь между экзекьютором и аллокатором как бы прерывается\.

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

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

Когда я пишу код, обычно происходит следующее: я наследую экзекьютор, который использует какой\-то сокет или то, что дано\. Будучи уверенным, что используешь его экзекьютор даже не задумываешься об этом\. А затем, в main, понимаешь, что нужны четыре разных потока, то есть четыре разных контекста, каждый со своим экзекьютором\. Раздаешь их, определяется место выполнения работы, поток выполнения и синхронизация, которые хочешь предоставить\. Поэтому экзекьютор – это не просто новая фича, а целая концепция\.

_Джейсон Тернер_: Экзекьюторы чем\-то похожи на параллельные алгоритмы?

_Роберт Лихи_: Не уверен, но думаю, что\-то общее у них есть\. Экзекьюторы более гибкие, их можно написать с нуля\.

_Джейсон Тернер_: Как тогда выглядит интерфейс экзекьютора, написанного с нуля?

_Роберт Лихи_: Сейчас интерфейс экзекьютора очень прост\. Под простым интерфейсом экзекьютора буквально подразумевается один точечный объект настройки, который вызывается экзекьютором, передаешь его экзекьютору и тому, что может быть вызвано без аргументов\. Он вызывает объект без аргументов внутри контекста выполнения, который также обрабатывается экзекьюторами\.

_Роб Ирвинг_: Теперь обсудим Boost\.Asio\. Расскажешь нам немного о том, как это будет выглядеть после выхода Networking TS?

_Роберт Лихи_: Дело в том, что Networking и Asio сейчас недостаточно функциональны\. Получаешь сокет TCP, сокет UDP или даже сырой сокет\. Мы же хотим предоставить возможность создавать все, что захотите в C\+\+\. Многие хотят иметь доступ к TLS по умолчанию, что действительно имеет смысл\. Например, если писать приложение для телефона, логично сделать так, чтобы создать незащищенное соединение было невозможно\. Потому что, если разрешить людям делать это, большинство так и поступит, будет использовать соединение без защиты\. Это все усложнит, что будет небезопасно по умолчанию, мы этого не хотим\. Но в то же время TS и Asio не стремятся работать с низкоуровневым компоновочным блоком\.

_Джейсон Тернер_: Итак, к вопросу о получении сокета TLS по умолчанию\. Поддерживает ли Networking TS шифрование?

_Роберт Лихи_: В самом предложении Networking нет возможностей для шифрования, но они есть в Asio\. В комитете также обсуждалось, какое шифрование принимается за стандарт, проведена ли реализация, а если проведена, то, в чем ее преимущество\. Лично я думаю, что стандартизация какой\-либо формы шифрования пошла бы на пользу, но мы хотим видеть Networking TS в 23\. Мы можем добавить что\-то, чтобы сделать шифрование\.

Например, в Asio поддержка TLS – это всего лишь пара классов\. Не нужно вносить какие\-то принципиальные изменения, но не все операционные системы поддерживают это\. Полагаю, что некоторые мобильные операционные системы не могут создавать сырые TCP\-соединения без определенного разрешения, которого нет у большинства приложений\. Я думаю, что в iOS такое есть, хотя я могу ошибаться насчет этого\.

_Джейсон Тернер_: То есть, по сути, ты получаешь TCP, UDP, IPV для IPv6?

_Роберт Лихи_: Да, но не уверен, есть ли сырые сокеты в TS\. В Asio они есть, но они скорее похожи на асинхронный аналог сокетов Беркли\. Вообще многое в TS похоже на POSIX\. Не знаю, есть ли такое в TS, но уверен, что в Asio есть ICMP\.

Самое важное, что мы получим от TS в сочетании с экзекьюторами, это модель того, как бы выглядел и функционировал асинхронный ввод\-вывод, оставляя возможность компиляции библиотек, которые просто принимают параметр шаблона, являющегося асинхронным потоком или что\-то в этом роде\. Здесь все взаимосвязано, не важно, используются ли IOUring, порты завершения \(IOCP\), файл или сокет\.

Мы как бы имеем заготовки для выполнения самых простых операций с сокетами\. Не знаю, в каком объеме, но IP/TCP, UDP, а также V4 и V6 определенно получим\.

_Джейсон Тернер_: Итак, сейчас нам остается ждать завершения работы с экзекьюторами, а по большей части предложение Networking почти готово к реализации\.

_Роберт Лихи_: Все стабильно, документы на рассмотрении\. В последний раз нам удалось договориться об обновлении некоторых старых идиом, чтобы привести TS в соответствие с экзекьюторами TS\. Использовались старые паттерны из C\+\+11\.

_Джейсон Тернер_: Я думал, что корутины, экзекьюторы и предложение Networking как\-то связаны\. А придется ли вносить изменения предложение Networking, чтобы воспользоваться преимуществами сопрограмм, или они уже были внесены?

_Роберт Лихи_: Насколько я помню, больше года назад в Белфасте мы одобрили этот документ\. Нам очень понравилась эта идея, потому что структура TS включает в себя механизм, называемый completion tokens\. То есть, когда передаешь последний аргумент, когда начинается операция, последний аргумент не является обработчиком завершения\. Необязательно вызывается функция\. Токен дает нам возможность узнать, какую функцию следует использовать для обозначения завершения\. Разница в том, что можно полноценно настроить механизм отчетов о завершении\. Итак, волшебным образом можно выполнить любую операцию в Networking TS или написанную в стиле Networking TS, и можно передать ей токен под названием Use Future\. И внезапно, вместо вызова функции, операция возвращает future и внутри использует promise, совершенно незаметно для пользователя\.

Что касается вашего вопроса, хочется ответить "да", однако есть большое "но"\. Проблема в том, что как только вызывается так называемая функция инициирования, то есть функция, которая запускает процесс, операция уже началась, она как бы вернулась к тебе\. И часто где\-то в фоновом режиме уже запущена операция\. Пытаясь преобразовать свою инициирующую функцию во что\-то, что использует сопрограммы, тот факт, что она была отключена и запущена в фоновом режиме и могла завершиться, означал, что между первой приостановкой сопрограммы и возможным возобновлением произошло состояние гонки\. В итоге, пытаясь превратить любую из этих операций во что\-то, что использует сопрограммы, нужно использовать мьютекс, что, по сути, противоречит C\+\+ и абстракциям с нулевой стоимостью\.

Что касается механизма работы completion tokens, при настройке, функция запуска может работать как функция, которая инкапсулирует то, что операция будет выполнять, чтобы запуститься и запустить целую кучу аргументов\. Можно немного отложить это и начать операцию снова позже\. Таким образом, можно незаметно преобразовать один из них во что\-то, что использует сопрограммы\. Он просто начнет так называемое инициирование, чтобы начать выполнение операции\. Он фиксирует все аргументы, помещает их куда\-то, а затем ожидает первой приостановки работы сопрограммы и начинает операцию\.

Крис, автор документа N3747, хотел создать что\-то вроде поддержки сопрограмм, а для этого ему нужно было везде добавить мьютекс \(mutex\), что не улучшает производительность\. Множество механизмов, которые он внедрил значительно упрощают реализацию самих операций\. Вызываешь одну вспомогательную функцию, передаешь ее лямбде, и она делает все за вас\. Так мы получаем возможность написать операцию, которая поддерживает сопрограммы, promises, futures и вообще все, о чем только мечтаешь\. Крис называет это универсальной моделью для асинхронных операций\. Если загуглить универсальную модель асинхронных операций, то можно найти [документ](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1943r0.html) Криса о ранней версии completion tokens, но принципы все те же\.

_Джейсон Тернер_: Используются ли специальные стратегии выделения памяти или полиморфные аллокаторы в стандарте C\+\+?

_Роберт Лихи_: Мы их не используем, скорее, из\-за финансового вопроса\. Я вообще стараюсь не использовать статическое распределение памяти\. А стратегия двойной буферизации как раз помогает в этом\. Если волнует только пропускная способность, то тот факт, что часть данных стала доступной на микросекунды раньше, не имеет значения\.

Главное — это то, что в какой\-то момент при работе с очень большим соединением с высокой пропускной способностью, я останавливаю распределение\. То есть, мы пытаемся создать буфер для отправки по TCP\. Когда размер этого буфера превысит 10 килобайт, необходимо отправить его, поменять местами буферы и заполнить следующий\. Допустим, мы используем буфер памяти из библиотеки format\. В итоге он заполняется, потому что он работает в JSON\. Они как бы векторные\. Их размер уменьшается\. А затем, когда помещаешь в них JSON, они начинают распределяться и изменяться в размере\. В какой\-то момент вам понадобиться выполнить самое большое распределение\. И после этого они больше не будут заполняться, а соединение может выдать огромное количество данных\. Буквально десятки или сотни гигабайт данных\. И он просто больше не распределяет, потому что он помещает JSON непосредственно в этот буфер с помощью библиотеки форматов, буфер заполняется полностью\. Так, что больше не нужно все это распределять\. А затем он просто заполняет этот буфер\. Итак, пока он ожидает команды от операционной системы, он все еще генерирует данные из внутренней базы данных, продолжая менять их местами\.

Наша компания обрабатывает данные рынка в реальном времени\. Мы применяем всевозможные стратегии распределения\. Потому что здесь имеет значение каждая микросекунда инкрементной задержки\.

_Джейсон Тернер_: У меня есть еще один вопрос\. Я заметил, что некоторые из самых крупных стандартных библиотек, Boost\.Regex, Filesystem, Ranges, Parallel Algorithms отстают в разработке фактической реализации внутри стандартных библиотек, таких как LIB C\+\+ или Clang, которая пока не имеет параллельных алгоритмов\. Как думаешь, после утверждения Networking и внедрения экзекьюторов, не столкнемся ли мы с такой же проблемой при реализации нашей стандартной библиотеки?

_Роберт Лихи_: Хороший вопрос\. Я не думаю, что будет много проблем\. Возможно, Asio будет использоваться в качестве эталонной реализации\. Крис много делает для того, чтобы обеспечить совместимость работы Networking с Asio на данном этапе\. Так что, думаю, нам повезет\. Реализация зависит от вендоров\. Если они захотят создать свою библиотеку с нуля, на это уйдет немало времени\. А библиотека TS уже довольно большая, и много чего предстоит реализовать, как и с экзекуторами, поэтому затрудняюсь ответить\.

Я знаю, что управление пакетами в C\+\+ выглядит весьма странно\. Если хочется использовать Networking TS прямо сейчас, привыкай использовать Boost\.Asio и Asio и получишь даже больше, чем предлагает TS\. Будет возможность использовать синхронную обработку уникальных сигналов, что действительно полезно\. В TS такая возможность даже не рассматривается\. В таком случае не нужно будет загружать Boost\. Многие недолюбливают Boost, поэтому Крис предоставляет автономный доступ к Asio\. Ты просто можешь использовать Asio и все\. Мы часто используем Boost, но не в этом проекте\. Здесь мы используем автономный Asio, который отлично работает\.

Я бы посоветовал тем, кто не боится управлять пакетами и зависимостями между ними, использовать Asio, пока TS не достигнет достаточного уровня\. Это прекрасная возможность не зависеть от некоторых языковых особенностей\.

![0795_Podcast_Networking_TS_ru/image7.png](https://import.viva64.com/docx/blog/0795_Podcast_Networking_TS_ru/image7.png)

На этом текстовая трансляция подкаста заканчивается\. Спасибо, что уделили время, надеемся, вы получили много новой информации, которая пригодится в будущем\.

В разделе "Ресурсы" можете найти все необходимые ссылки на информацию из приведенного текста, а также ссылки на ведущих данного эпизода\. Надеемся, такой формат будет интересен вам в дальнейшем\.

Спасибо за внимание, до новых встреч\! :\)

## Ресурсы

Подкаст

* [Стандартизация Networking TS](https://cppcast.com/robert-leahy-networking-ts/)

Новости

* [Компьютерная игра с открытым свободным кодом Flappy Hero, написанная на C\+\+](https://preshing.com/20201126/a-small-open-source-game-in-cpp/)
* [Блок\-схема инициализации C\+\+20](https://old.reddit.com/r/cpp/comments/k2cozv/the_c_20_initialization_flowchart/)
* [В память о Бимане Доусе](https://old.reddit.com/r/cpp/comments/k58a2u/beman_dawes_has_passed_away_boost_filesystem_wg21/)

Ссылки

* [Networking TS с нуля: объекты ввода\-вывода \- Роберт Лихи \- CppCon 2020](https://www.youtube.com/watch?v=xgXFZ-rYc4w)
* [N3747 – Универсальная модель асинхронных операций](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf)
* [P2161 – Извлечение экзекьютора по умолчанию](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2161r2.pdf)
* [Boost\.Outcome](https://github.com/ned14/outcome)

Ведущие

* Роб Ирвинг [@robwirving](https://twitter.com/robwirving), Джейсон Тернер [@lefticus](https://twitter.com/lefticus)

Спонсоры

Спонсор этого эпизода CppCast – PVS\-Studio\. Команда продвигает регулярное использование статического анализа кода и инструмент статического анализа PVS\-Studio, предназначенный для обнаружения ошибок в коде программ на языках C, C\+\+, C\# и Java\. Компания предоставляет платный инструмент, а также различные бесплатные варианты лицензий для разработчиков открытых проектов, экспертов Microsoft MVP, студентов и других\. Анализатор активно развивается, проводит регулярные тесты на поиск новых ошибок, расширяет возможности интеграции\. Например, недавно PVS\-Studio разместила на своем сайте статью, посвященную [анализу pull request\-ов в Azure DevOps при помощи self\-hosted агентов](https://pvs-studio.ru/ru/blog/posts/cpp/0751/)\. Используйте промокод \#cppcast на странице [загрузки](https://pvs-studio.ru/ru/pvs-studio/download/) для получения лицензии на месяц\.

А также JetBrains, генератор умных идей и создатель инструментов IntelliJ, pyCharm, ReSharper\. Чтобы помочь вам стать гуру C\+\+, они предлагают CLion, IntelliJ IDEA и ReSharper C\+\+ – многофункциональное расширение для Visual Studio\. Исключительно для CppCast, JetBrains предлагает скидку 25% на ежегодные индивидуальные лицензии для обоих инструментов C\+\+, которая распространяется на новые покупки и продления\. Используйте код JetBrainsForCppCast во время оформления заказа по адресу JetBrains\.com для получения скидки, не упустите такую возможность\!