спп стдлиб

красивом

/0

Скоро будет.

2020 выйдет через три года.

Оно то конечно будет. Но вопрос в том, будут ли разработчики восокоуровневых библиотек использовать этот C++ функционал, или будут продолжать использовать напрямую API от операционной системы.

И сеть будет. И гуй будет. Там уже все будет.

Networking TS вообще-то на Boost Asio основан, не особо низкоуровневый API.

Бери Asio и вперёд. На самом деле, подход, который продвигается в stdlib, стал популярен относительно недавно (10 лет назад). До этого в C++ были популярны такие библиотеки, как ACE. Смотря назад, можно сказать, что это даже хорошо, что в стандарт ничего такого не приняли.

Есть какое-то логическое объяснение?

Бритва Оккама © (wikipedia.org).

Потому что язык живет уже 35 лет, а понятие «лучшая сетевая библиотека» трансформируется каждые лет 7 вслед за изменениями API современных ОС. Вот раньше `std::locale` в стандарт завезли - а теперь он никому не нужен, и приходится таскать мёртвый груз.

А зачем это нужно в стандартной библиотеке?

Это я знаю. Но тем не менее, соменаюсь, что тот же Qt будет свою сетевую подсистему спешить переписывать на C++ STL Networking.

Чтобы хипсторок не напрягался попивая смузи в опенспейсе.

вслед за изменениями API современных ОС.

и что за последние 7 лет поменялось?

и что за последние 7 лет поменялось?

Появился io_uring на смену epoll и aio. В asio его всё еще нет.

Go и gRPC отхватили себе 90% ниши «очень быстрых CRUD».

Rust захватил нишу петпрожектов для души.

Carrier/cloud железяки-апплаенсы перешли с фряхи на DPDK/VPP с юзерспейсным стеком, тоже стандартные фреймворки мимо.

Стриминг видео перешёл на WebRTC, а там свой гугловый лисапед для сети (имхо намного лучше asio).

Итого - boost::asio и подобное сейчас нужен либо динозаврам, либо трейдерам, т.е. маргиналам. И смысл стандартизировать маргинальную технологию?

Появился io_uring на смену epoll и aio. В asio его всё еще нет.

интересно, надо почитать

но тем не менее, все существовавшие до этого API от этого работать не перестали же

Итого - boost::asio и подобное сейчас нужен либо динозаврам, либо трейдерам, т.е. маргиналам.

Нафиг он трейдерам, он же тормозной?

Rust захватил нишу петпрожектов для души.

Незаметно. Попадается крайне редко и то какая-то чушь собачья типа «клиента» AUR.

цп стыдлив?

Вот раньше std::locale в стандарт завезли - а теперь он никому не нужен, и приходится таскать мёртвый груз.

И сеть в стандарте тоже нафиг не нужна. Как выше уже отметили, ASIO это сравнительно высокоуровневая вещь. А точнее – ни туда, ни сюда. Кому это надо в низкоуровневом системном языке – я хз. Протоколы пишут на совсем низкоуровневщине (даже на жаве), а прикладному софту универсальная работа с сетью не нужна. Плюс, добавлю от себя, оверхед на лишний слой (в т.ч. в рантайме: оно там pluggable ЕМНИП).

сеть в стандарте тоже нафиг не нужна

конечно нужна

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

Ну может и нужна… Вопрос философский. Мне аргумент @snizovtsev кажется более существенным. Зачем стандарту распухать, если нужные мультиплатформенные либы и так есть.

Прикладнику gRPC удобнее чем Asio. Либо он может вообще на всякие MQ смотреть. Ковыряться напрямую с сокетами (пусть и в обертке Asio) на при реализации инфраструктурных вещей, тех же gRPC/MQ.

Ну есть же в стандартных библиотеках работа с файлами.
Значит и работа с сетью должна быть.

Тут несколько аспектов, как показал рост популярности Java/.NET популярность у прикладников завоевывают платформы. Где-то году в 2011-2012 на Going Native, ЕМНИП, Саттер говорил, что для того, чтобы вернуть популярность, С++ надо становиться платформой и предоставлять и сетевые средства, и развитую многопоточность, и работу с БД, и графику и т.д.

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

С третьей, как мы видим по скорости развития библиотек, комитет не может конкурировать с разработчиками. Это и понятно, и ожидаемо.

И тут возникает вопрос, а на какую нишу С++ нацелен с т.з. комитета? Какие библиотеки/средства в С++ нужны? Я не уверен, что такая сформулированная и понимаемая позиция есть.

Работа с файлами тоже разная бывает, где-то просто байты читать/писать, а где-то надо для sparse файлов дергать DeviceIoControl (ага, на некоторой ОС аналога lseek не достаточно).

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

А всё потому что Java EE – говно собачье. Что является доказательством того простого соображения, что

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

А потому и не должен.

И тут возникает вопрос, а на какую нишу С++ нацелен с т.з. комитета?

Честно говоря, мне кажется, они его закапывают… Ладно, просто вылизывают что уже есть – как умеют. Все эти бесконечные усовершенствования (читай – усложнения) языка выглядят как попытки слона из басни «Ералаш» всем угодить. (Кто-то каментил что мол все новшевства в C++20 – ответ на пожелания кодеров.) А основная идея, сформулированная Страуструпом, не меняется.

Мне аргумент @snizovtsev кажется более существенным. Зачем стандарту распухать, если нужные мультиплатформенные либы и так есть.

Обычно этот аргумент озвучивают вмести с жалобами на нехватку пакетного менеджера для C++. Я бы предпочёл называть его менеджером зависимостей, потому что пакеты - это про другое, но крестанутые предпочитают так. В C++ с этими менеджарами действительно туго. Есть Conan, который неожиданно на Python и есть vcpkg, который хоть и на C++, но не поддерживает версии зависимостей. Поддержку версий туда хотят добавить, но как-то вяло и как-то криво.

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

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

А зачем? Уже ведь есть CMake и прочии auto tools, которые всё это тестят и подгоняют на этапе сборки? Или речь о бинарных зависимостях?

В C++ с этими менеджарами действительно туго

Их просто слишком много. conan, vcpkg, кто-то просто считает, что менеджер зависимостей в С++ == системный пакетный менеджер, кто-то использует сабмодули гит (привет, mdbx и gtest), CMake со своим FetchContent (привет, grpc). Собственно всё в лучших традициях.

В той же Java, если библиотека существует, значит она устанавливается из maven-овских репозитариев. И разработчики заботятся о доступности их творения. В С++ - исходники есть? Есть. Налетай, компиляй.

Вот раньше std::locale в стандарт завезли - а теперь он никому не нужен, и приходится таскать мёртвый груз.

А что теперь вместо него?

Их просто слишком много. conan, vcpkg, кто-то просто считает, что менеджер зависимостей в С++ == системный пакетный менеджер, кто-то использует сабмодули гит (привет, mdbx и gtest), CMake со своим FetchContent (привет, grpc). Собственно всё в лучших традициях.

Это их сейчас слишком много и все в каком-то полузачаточном состоянии, потому что года 2 - 3 назад уж очень сильно припёрло и вдруг их начали писать... в лучших традициях фрагментации велосипедов. Практически как тот же десктопный Linux.

В той же Java, если библиотека существует, значит она устанавливается из maven-овских репозитариев. И разработчики заботятся о доступности их творения. В С++ - исходники есть? Есть. Налетай, компиляй.

В Java библиотеки распространяются в виде Jar архивов, внутри которых байткод и иногда ресуры. Java байткод одинаков везде и даже не оптимизируется компилятором, поскольку вся оптимизация осуществляется в JIT. С такими языками как C/C++ сделать так же просто нельзя, там нет байткода. А даже если паковать промежуточный байткод из LLVM, всё равно платформонезависимо не получится. Что касается компиляции, то в C/C++ она гораздо сложнее, с кучей проверок всякими auto tools, макросами, включающими или отключающими целые блоки кода по условиям. Я в общем не против компилировать C/C++ библиотеки самостоятельно, но даже это в C/C++ сделано слишком сложно и почти всегда с кучей костылей или патчей.

С такими языками как C/C++ сделать так же просто нельзя

Да тут всё сложнее. Но тот же Conan пытается адресовать эту сложность вводя конфигурации и распространяя бинарные пакеты под типовые конфигурации. Конечно, если требования становятся более специфичными, то приходится собирать из исходников, но и тут Conan упрощает жизнь.

Я всё-таки говорил не о проблемах распространения бинарников, а о том, что сами разработчики в большинстве случаев ничего не делают для распространения своих библиотек через Conan. Собирают совершенно другие люди.

Я всё-таки говорил не о проблемах распространения бинарников, а о том, что сами разработчики в большинстве случаев ничего не делают для распространения своих библиотек через Conan. Собирают совершенно другие люди.

Потому что Conan довольно молод и недостаточно сильно распространён. Хотя Павел Филонов ещё в начале 2017 о нём очень хорошо рассказал на конференции плюсовиков https://www.youtube.com/watch?v=W9DBJunyZyQ Это банальная инерция.

Проблема не в отсутствии поддержки сети, а в отсутствии развитой инфраструктуры для распространения библиотек.

Для Java есть maven, для Rust - cargo/crates.io, для Go - гошные пакеты.

А для С++ до сих пор популярна папочка 3party в корне проекта. Стыд и срам.

Rust захватил нишу петпрожектов для души.

Ахах… Недурно ) Вот я сам пишу на Rust, и в продакшн, и для души. И в долговременную тягловую силу «душевных» проектов в опенсорсе я верю больше, чем в маркетинговые раскрутки.

Лучшее что разработчики на C++ могут сделать для распространения своих библиотек через Conan и не только - это, как ни странно, не мешать. В этом случае пакеты появятся без их участия и воли на то во всех популярных репозиториях, которые бы они сами лично никогда в жизни не охватили физически. Однако по факту это означает весьма высокие требования к культуре самих разработчиков и качеству и переносимости их кода. Подробнее см. например Don’t package your libraries, write packagable libraries.

У того же Conan куча проблем, самая главная это пожалуй крайне низкое качество и малое количество community-рецептов для пакетов, и для реального применения их скорее всего придётся переписывать. То есть то что предлагается в дефолтной репе можно рассматривать только как примеры (зачастую неудачные) или скорее рекламу платных сервисов BinTray. Это не большая проблема в энтерпрайзе, где есть ресурсы и поднята инфраструктура для хранения предкомпилированных бинарников под целевые таргеты, а в опенсорсе, где никто никому ничего не должен, с этим сложнее. Лично я бы для открытого проекта рекомендовал FetchContent/ExternalProject из CMake с обязательной возможностью для потенциальных майнтейнеров отключить этот механизм полностью и передать свои версии зависимостей вручную.

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

Нет, конкретно с Conan дело совсем не в этом, а в крайне дурной политике компании-разработчика (BinTray), для которой Conan - это всего лишь реклама их платной хранилки (Artifactory), и они вендорлочат рецепты в дефолтной репе как могут.

Например, у них есть вредная политика, согласно которой сгенерированные config-файлы для CMake (это чтобы в клиентской сборочной системе работал find_package()) должны быть удалены, и вместо них использован файл с таргетами, синтезированный Conan по описаниям в рецепте. То же самое касается pkg-config. С точки зрения автора библиотеки это совершеннейшее свинство, потому что пользователь, делая find_package() получит не то что задумал и задокументировал автор, а фигню которую синтезировал Conan. Если автор написал и экспортировал дополнительные функции в CMake для своей библиотеки (многие библиотеки так делают), это тоже всё будет вырезано.

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

Спешу подчеркнуть, что ничего из этого не вызвано техническими ограничениями Conan как инструмента. Это исключительно политики на пакеты в дефолтной репе. Понятно, что это репа работает на мощностях вендора, и чтобы разместить там что-то своё, надо подчиняться их правилам. Но как следствие, глядя на просто изуродованные под эти политики рецепты, рекомендовать Conan для широкого круга разработчиков я не стану.

А зачем?

Ну типа чтобы при скачивании выбрать подходящую версию. Хотя может я и гоню.

Мой поинт в том, что не надо >1 репозитория (по технологии, развёрнуто может быть несколько), не надо пакетировать в rpm, deb, conan, vcpkg, etc. Повторюсь - как в Java, maven - это стандарт распространения библиотек, как pip в Python, и т.д.

Что эта вариативность даёт? Проблемы пользователям библиотек. Дополнительную работу для сообщества по подготовке пакетов. А плюсы-то где?

Ну так conan и хранит информацию о версии библиотеки, компиляторе, ОС и опциях сборки.

Ага, т.е. они уже бинарники объектники хранят. В таком разрезе я не думал, имел в виду только совместимость сырцов с архитектурами. Хотя те же maven-репы тоже скомпилятое хранят (а сорцы опционально), а у меня видимо гента головного мозга. :)

Разве включение в стандарт сетевой библиотеки не подразумевает, что все платформы, для которых реализован язык должны включать в себя работу с сетью? Это излишнее ограничение на язык

Сделают как в С с многопоточностью - объявят необязательным к реализации и введут feature test макрос для проверки.

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

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

ну тут тогда тот же вопрос и к потокам, но завезли же.

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