Здравствуйте, Великий Мессия, Вы писали:
ВМ>в целом проблема здесь другая
Проблема здесь та, что есть С++ "на бумаге", а есть C++ "в компиляторе". И в обычной жизни это две большие разницы.
Когда в каком-то компиляторе нет std::start_lifetime_as, даже если компилятор имеет ключик -std=c++23, то это дело еще можно какими-то собственными функциями-заглушками обойти.
А вот когда функциональность по работе с сетью завязана, условно, на установку опции nodelay для сокета, и на одном компиляторе эта опция уже есть, тогда как на другом -- нет, вот тут все будет гораздо веселее.
Ну и чем больше распухает стандарт (особенно в части stdlib), тем дольше будет путь от С++ "на бумаге" до C++ "в компиляторе".
Вот ейбоху комитет бы лучше озадачился стандартом описания зависимостей для C++ проекта. Чтобы vcpkg/conan/etc могли понимать этот стандарт и подтаскивали бы к проекту то, что требуется. Тогда обычный человек в два клика мог подключить к себе в проект конкретную версию Asio или POCO, и делал бы работу с сетью как ему хочется/нравится. Не дожидаясь включения std::networking в C++29 с реализацией в 2033-ем году.
Здравствуйте, LaptevVV, Вы писали:
BFE>>>>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>>К C++ это какое имеет отношение? LVV>Ну дык я понял, что отдельный стандарт — это об общих принципах сетевой модели.
POSIX определяет API в виде деклараций функций на языке C. При этом сам стандарт языка Си — это отдельный стандарт, включающий в себя библиотеку языка Си.
Соответственно, я не вижу причин, почему бы не быть стандарту в виде деклараций классов на С++, которые могут использоваться для сетевого взаимодействия и которые не входят в стандарт языка С++.
BFE>>Опять же сокеты — чего в них хорошего? Неужели лучше ничего нельзя придумать? Не верю. LVV>Ну, придумай. Зачем ждать милостей от природы ? LVV>Сокеты, насколько мне известно, придумал Кен Томпсон для берколеевской версии юникса еще году в 1981-1983 примерно... LVV>Они прекрасно отделяют клиента от сервера.
Во-первых, задач много, а я один.
Во-вторых, всё уже вроде бы придумано.
Я точно помню, что читал статью, в которой рассказывалось о разработке технологии коммуникации на основе обмена буферами данных, то есть без копирования. Быстрый поиск вывел меня на статью wikipedia Zero-copy. Если уж стандартизировать, то что-то передовое, а не полувековой давности технологию.
Здравствуйте, LaptevVV, Вы писали:
BFE>>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку. LVV>Ну, есть же модель OSI LVV>Там есть tcp/ip и udp
Там API не определён.
Ну и мой любимый вопрос, к какому уровню OSI относится тунелирование IP-трафика через HTTP?
LVV>И фактический стандарт — сокеты. LVV>Я не в курсе — сокеты в nix-системах стандартизированы официально ?
Да, но есть нюансы.
На уровне "открыть TCP-сокет и куда-нибудь приконнектиться" всё более-менее одинаковое. А вот на уровне "получить список сетевых интерфейсов", "получить список локальных IP-адресов", "узнать, через какой интерфейс уйдёт пакет, если послать его по адресу N", на уровне UDP-мултикастинга системы расходятся. Не то, чтобы совсем уж в разные стороны, но заметно.
А есть еще более интересные уровни. Например, "получить UID процесса, который приконнектился к нашему локальному серверу через loopback" — тут уж совсем системно-зависимые дебри.
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>... SaZ>>>Вот интересно, а почему тогда не депрекейтнули std::bit_cast? Вроде как он теперь не нужен?
ВМ>>нужен ВМ>>bit_cast побитово копирует в новый тип ВМ>>а start_lifetime_as конструирует и возвращает указатель
SaZ>Это всё понятно, но тут два момента: в каких случаях теперь нужен bit_cast, когда можно сделать start_lifetime_as и просто скопировать? И второе — имхо, название неудачное, какой-нибудь bit_copy более явно отразил бы суть.
bit_copy думаю подразумевал бы как минимум пару аргументов
а bit_cast один, причем имплиситно еще и видно в какой тип
мысленно представляем что делаем memcpy с гарантированно равными по размерам типами
и тривиально копируемы
start_lifetime_as лучше вбить в ктыв поиск
был знатный флудо разбор когда и как он там нужен
и в чем разница между reinterpret_cast
BFE>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку.
Ну, есть же модель OSI
Там есть tcp/ip и udp
И фактический стандарт — сокеты.
Я не в курсе — сокеты в nix-системах стандартизированы официально ?
На уровне API Linux — фактически да.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Великий Мессия, Вы писали:
ВМ>будет на всех компиляторах
Когда (и если) будет, тогда и поговорим.
Пока же есть пример с std::format.
Если проект начался до включения std::format в стандарт и использовал fmtlib, то смысла переходить в проекте на std::format нет.
Если проект начался с std::format, но потом вынужден был пойти на платформу/компилятор, где std::format еще нет (реальность, увы), то проще выбросить std::format в пользу fmt::format и дальше оставаться на fmtlib.
Может лет через 5 ситуация будет другая, но пока fmtlib выглядит предпочтительнее std::format.
Есть сильные подозрения, что касательно std::net будет аналогично. Что наводит на мысль, что таки не нужно лохматить бабушку и пытаться втащить std::net в стандарт.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>для модулей нужен минимум С++20 S>На С++20 проектов вагон и маленькая тележка, но модули не использует никто.
сильное заявление как для того кто не знает как использовать модули
вы в курсе что
1) только пол года назад msvc/clang/gcc достигли "почти" полной поддержки C++20
2) только на VS можно модули использовать из коробки, а для других нужна build system cmake/meson/итд
3) только 8 месяцев назад cmake добавил поддержку модулей, и есть еще нюанс с использованием import std, который должен быть исправлен в ближайшем cmake релизе
4) только где то 2 месяца назад meson начал экспериментальную поддержку модулей
5) для использования модулей придется провести рефакторинг проекта а так же переделать cmake/meson файлы
не говоря о том что "на С++20 вагон проектов" слишком сильное заявление
даже форумный марти все еще сидит на C++17
и я слежу как минимум за фиксами в clang по модулям
и если бы "не использовал никто", то баг репортов не было вообще
поэтому можно сказать что модули вот вот только стали поддерживаться в С++
и необходимо время не менее 5 лет
что бы новые проекты изначально начали писать на них
и желание разрабов старого легаси переводить на модули
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>Здравствуйте, SaZ, Вы писали: ВМ>>... ВМ>>либо видосик посмотреть ВМ>>https://www.youtube.com/watch?v=pbkQG09grFw
SaZ>Спасибо, проанализирую на досуге, хотя пока всё равно чётко для себя не понимаю.
да все эти нюансы нужны как правило для собеседований
когда зарплатодатель не кого то переманивает, кого уже обкатали в др компании, а нанимает с улицы
и не знает как выстроить леммингов
лемминг знаюший больше всего ключевых слов, получает проходной бал
и идет говнокодить без этих всяких модных нововведений
во всем остальном правило простое
в большинстве случаев начиная с С++23 вместо reinterpret_cast(потому что компилятор умный и может все это превратить в UB) теперь надо юзать start_lifetime_as
если это шаровара, то можно по старинке на это все забить
и юзать reinterpret_cast, релиз тестами это так или иначе сразу выловиться если где то сломается
тоже самое и bit_cast, ну лень вам писать memcpy, пишите bit_cast, стильно модно, благородно
мне например bit_cast std::int*_t <-> std::array зашла для своих from_/to_le/ne_bytes конверций как в расте
вообщем автор asio слишком звездный или у него руки и ноги связаны nda
поэтому он ни с кем не общается в опенсорс комюнити
и известный фалько, предлагает форкнуть asio
Здравствуйте, Великий Мессия, Вы писали:
ВМ>вообщем автор asio слишком звездный или у него руки и ноги связаны nda
Или тупо устал и подвыгорел? При 20+ годах работы вполне вероятно.
ВМ>поэтому он ни с кем не общается в опенсорс комюнити ВМ>и известный фалько, предлагает форкнуть asio
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>вообщем автор asio слишком звездный или у него руки и ноги связаны nda
N>Или тупо устал и подвыгорел? При 20+ годах работы вполне вероятно.
он комитит в репу
принимает к сведению и иногда реагирует на иссуес
но в дискуссии не вступает
ВМ>>поэтому он ни с кем не общается в опенсорс комюнити ВМ>>и известный фалько, предлагает форкнуть asio
N>Форк и "напишем новый" как-то разные вещи?
начинают с форка
а в рассуждениях заходят за написание нового
с новым дизайном
Unfortunately he has a well-earned reputation for being unresponsive to emails and GitHub issues.
S>Странно, неужели все так кардинально изменилось за прошедшие 5 лет? В 2020-ом возникли сложности с Asio, мне Крис ответил буквально через полчаса.
кто знает
может был прецедент
у нас есть а АУ агент 007, джеймс бонд ктыва
который с ним бухал
ТЁМЫЧ
можно заслать его на пивасик
пусть расспросит
получим инсайды
Здравствуйте, Великий Мессия, Вы писали:
ВМ>любопытный флем на эту тему разгорелся в рассылке буста в августе(сейчас затух)
... ВМ>и известный фалько, предлагает форкнуть asio
Я за новостями не слежу, но не так давно мы тут обсуждали, что поддержку сети собираются добавить в стандарт. Снова нет?
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>любопытный флем на эту тему разгорелся в рассылке буста в августе(сейчас затух) BFE>... ВМ>>и известный фалько, предлагает форкнуть asio
BFE>Я за новостями не слежу, но не так давно мы тут обсуждали, что поддержку сети собираются добавить в стандарт. Снова нет?
за сегодня на реддите уже два топика
для тебя стараются!
Мда...
Понятно.
Действительно, лучше никак, чем как std::filesystem.
Опять же политические мотивы прослеживаются...
А ещё складывается впечатление, что для написания реальных приложений авторам не хватает квалификаций.
Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface?
Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку.
Здравствуйте, B0FEE664, Вы писали:
BFE>Я за новостями не слежу, но не так давно мы тут обсуждали, что поддержку сети собираются добавить в стандарт. Снова нет?
Хотя, комитет в очередной раз может подложить большую свинью и таки принять средства для работы с сетью в стандарт. Одной диверсией больше, одной меньше, уже без разницы
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, B0FEE664, Вы писали:
BFE>>Я за новостями не слежу, но не так давно мы тут обсуждали, что поддержку сети собираются добавить в стандарт. Снова нет?
S>Очень надеюсь, что нет. S>Часть причин почему "нет" хорошо описана здесь: https://www.reddit.com/r/cpp/comments/1ic8adj/comment/m9pgjgs/
S>Хотя, комитет в очередной раз может подложить большую свинью и таки принять средства для работы с сетью в стандарт. Одной диверсией больше, одной меньше, уже без разницы
смотря кто что называет библиотекой с сетью
лававей по ссылке говорит о http/https итд
с этим да, проблемы
пропозлы есть
эпловцы вроде даже там отличились
но дальше подвижек не видно
насчет же низкоуровневой аля asio, то добавят после того как затянут экзекуторы
сроки насколько я помню
оптимистично в C++26
реалистично в С++30
Здравствуйте, Великий Мессия, Вы писали:
ВМ>смотря кто что называет библиотекой с сетью
Да кто бы чтобы не называл. Хоть даже примитивный accept/connect/read/write для обычных TCP/IP сокетов.
Не говоря уже про поддержку этого же самого, но поверх TLS/SSL.
ВМ>насчет же низкоуровневой аля asio, то добавят после того как затянут экзекуторы ВМ>сроки насколько я помню ВМ>оптимистично в C++26
В C++26 сомнительно, они же в комитете вроде как на пороге заморозки текущего драфта C++26. Типа того, что новые фичи туда не будут включать, а будут доводить до ума то, что есть.
Здравствуйте, so5team, Вы писали:
BFE>>Я за новостями не слежу, но не так давно мы тут обсуждали, что поддержку сети собираются добавить в стандарт. Снова нет?
S>Очень надеюсь, что нет. S>Часть причин почему "нет" хорошо описана здесь: https://www.reddit.com/r/cpp/comments/1ic8adj/comment/m9pgjgs/
S>Хотя, комитет в очередной раз может подложить большую свинью и таки принять средства для работы с сетью в стандарт. Одной диверсией больше, одной меньше, уже без разницы
Если это будет описано как "библиотека для работы с сетью в не сильно ограниченных по ресурсу системах", то я не вижу большой диверсионности: всё равно альтернативные стандарты поумирали нафиг. Интересно было наблюдать за XTI, например, но он не выжил.
А для чего-то масштаба RFID-наклейки — если там вообще будет C++ — отсутствие такой библиотеки и так будет очевидно.
Здравствуйте, netch80, Вы писали:
N>Если это будет описано как "библиотека для работы с сетью в не сильно ограниченных по ресурсу системах", то я не вижу большой диверсионности: всё равно альтернативные стандарты поумирали нафиг. Интересно было наблюдать за XTI, например, но он не выжил.
Вопрос не столько в API, сколько в качестве того, что получилось, что будет доступно в конкретном компиляторе и как это все будет меняться при смене версии компилятора.
А то получится, что в стандарте std::start_lifetime_as есть, а по факту в стабильных версиях компиляторов -- все еще нет.
Когда приложение завязано на внешнюю библиотеку, а не на stdlib все как-то проще. Взял условный Asio-1-32-0 и сидишь с ним пока все устраивает. А если и нашел ошибку, то можно сперва ее в своем форке исправить, патч в апстрим закинуть и все. Тогда как при обнаружении проблем с поведением условного std::net::tcp::socket на конкретной платформе хз как быть.
S>Когда приложение завязано на внешнюю библиотеку, а не на stdlib все как-то проще. Взял условный Asio-1-32-0 и сидишь с ним пока все устраивает. А если и нашел ошибку, то можно сперва ее в своем форке исправить, патч в апстрим закинуть и все. Тогда как при обнаружении проблем с поведением условного std::net::tcp::socket на конкретной платформе хз как быть.
Ну, быть примерно так же, как и с модулями.
Потихоньку пробовать и вводить в некоторых местах...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>>Если это будет описано как "библиотека для работы с сетью в не сильно ограниченных по ресурсу системах", то я не вижу большой диверсионности: всё равно альтернативные стандарты поумирали нафиг. Интересно было наблюдать за XTI, например, но он не выжил.
S>Вопрос не столько в API, сколько в качестве того, что получилось, что будет доступно в конкретном компиляторе и как это все будет меняться при смене версии компилятора. S>А то получится, что в стандарте std::start_lifetime_as есть, а по факту в стабильных версиях компиляторов -- все еще нет.
C++23 не все компиляторы еще поддерживают в полной мере
S>Когда приложение завязано на внешнюю библиотеку, а не на stdlib все как-то проще. Взял условный Asio-1-32-0 и сидишь с ним пока все устраивает. А если и нашел ошибку, то можно сперва ее в своем форке исправить, патч в апстрим закинуть и все. Тогда как при обнаружении проблем с поведением условного std::net::tcp::socket на конкретной платформе хз как быть.
в целом проблема здесь другая
стандарты штампуются быстрее чем компиляторы успевают их поддерживать в полной мере
и нет никакого регламанта по времени для этого в целом
даже С++17 в нюансах по моему еще не все реализовано
не говоря уже про С++20
а вы хотите С++23
вообщем то надо ждать очередного опроса С++ от комитета
где каждый должен высказать свое недовольство о скорости выхода новых стандартов
и регламента по поддержке в компиляторе
мои замечания в этих вопросах как я вижу начали учитывать
например я писал в опросах недовольство что слишком много УБ в стандарте
и вуаля, комитет зашевелился и количество УБ начали по чуть чуть убирать
были и другие замечания, уже не помню за все года
но комитет в целом принимает сведения замечания в этих опросниках которые они создают каждый год
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>в целом проблема здесь другая
S>Проблема здесь та, что есть С++ "на бумаге", а есть C++ "в компиляторе". И в обычной жизни это две большие разницы.
тоже самое что я сказал, только другими словами
S>Когда в каком-то компиляторе нет std::start_lifetime_as, даже если компилятор имеет ключик -std=c++23, то это дело еще можно какими-то собственными функциями-заглушками обойти.
будет на всех компиляторах
в части сокетов в стандарт проталкивают то как это есть в asio
S>Ну и чем больше распухает стандарт (особенно в части stdlib), тем дольше будет путь от С++ "на бумаге" до C++ "в компиляторе".
в нюансах к сокету не будет
когда оимплементации будут, они будут сразу полноценными соответствуя стандарту
надо говорить о конкретной единице стандарта или библиотеки
nodelay не единица стандарта
S>Вот ейбоху комитет бы лучше озадачился стандартом описания зависимостей для C++ проекта. Чтобы vcpkg/conan/etc могли понимать этот стандарт и подтаскивали бы к проекту то, что требуется. Тогда обычный человек в два клика мог подключить к себе в проект конкретную версию Asio или POCO, и делал бы работу с сетью как ему хочется/нравится. Не дожидаясь включения std::networking в C++29 с реализацией в 2033-ем году.
в рамкаж же попытках стандартизации системы сборки вроде что то было?
во всяком случае ждите опросник от комитета
и там делайте замечания на интересующие вас темы
а то по ощущениям опрсник штурмуют миллионы леммингов юнити кодеров
из за которых стандарт плывет не туда куда надо
Здравствуйте, so5team, Вы писали:
S>... S>А то получится, что в стандарте std::start_lifetime_as есть, а по факту в стабильных версиях компиляторов -- все еще нет.
Вот интересно, а почему тогда не депрекейтнули std::bit_cast? Вроде как он теперь не нужен?
Здравствуйте, SaZ, Вы писали:
S>>А то получится, что в стандарте std::start_lifetime_as есть, а по факту в стабильных версиях компиляторов -- все еще нет.
SaZ>Вот интересно, а почему тогда не депрекейтнули std::bit_cast? Вроде как он теперь не нужен?
Так вроде бы use cases разные.
start_lifetime_as -- это когда у вас есть область памяти A, в которой лежат, скажем, std::byte. А вы хотите иметь корректный указатель на double, который указывает в эту область.
bit_cast -- это когда у вас в области памяти A лежит, скажем, std::uint64_t, а вы хотите получить оттуда новое значение, скажем, типа double. Причем это именно что будет новое значение, никак не связанное с областью памяти A.
Т.е., как я понимаю, bit_cast может быть реализован через start_lifetime_as, но наличие start_lifetime_as не отменяет use cases, в которых bit_cast может быть полезен.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>будет на всех компиляторах
S>Когда (и если) будет, тогда и поговорим.
до появления экзекуторов не появится
а я экзекуторов пока не вижу даже в пушреквестах трех std либах msvc/gcc/clang
S>Пока же есть пример с std::format. S>Если проект начался до включения std::format в стандарт и использовал fmtlib, то смысла переходить в проекте на std::format нет. S>Если проект начался с std::format, но потом вынужден был пойти на платформу/компилятор, где std::format еще нет (реальность, увы), то проще выбросить std::format в пользу fmt::format и дальше оставаться на fmtlib.
S>Может лет через 5 ситуация будет другая, но пока fmtlib выглядит предпочтительнее std::format.
S>Есть сильные подозрения, что касательно std::net будет аналогично. Что наводит на мысль, что таки не нужно лохматить бабушку и пытаться втащить std::net в стандарт.
ясно же что автор asio писать std::net не будет
в каждом компиле это будет своя имплементация
но проблем там я не вижу, сокеты просты как два пальца
это не регексп который в каждой std имеет свою производительность
и только сейчас MS оптимизировал свою самую медленную
все из за чего забуксовал std::net были экзекуторы
хотя я еще в 20 кажется году пытался полухину протолкнуть мысль
что бы он в комитете намекнул мол давайте std::net без асинхронщины протянем
за одно обкатаем
а экзекуторы и асинхронщину пусть добавляют уже когда первая будет готова
он отказался, мол если тянуть, то сразу полный std::net а не по частям
ну и в довесок сказал что синхронные сокеты уже никто не юзает
std::format имеет свою базу
а в fmt::format автор постоянно что то добавляет, обновляет, улучшает
нет смысла их сравнивать
хотя вроде он же писал пропозл на std::format ? так пусть этим и занимается, обновляет идеи дальше в стандарте
Здравствуйте, SaZ, Вы писали:
SaZ>Здравствуйте, so5team, Вы писали:
S>>... S>>А то получится, что в стандарте std::start_lifetime_as есть, а по факту в стабильных версиях компиляторов -- все еще нет.
SaZ>Вот интересно, а почему тогда не депрекейтнули std::bit_cast? Вроде как он теперь не нужен?
нужен
bit_cast побитово копирует в новый тип
а start_lifetime_as конструирует и возвращает указатель
Здравствуйте, so5team, Вы писали:
N>>Если это будет описано как "библиотека для работы с сетью в не сильно ограниченных по ресурсу системах", то я не вижу большой диверсионности: всё равно альтернативные стандарты поумирали нафиг. Интересно было наблюдать за XTI, например, но он не выжил. S>Вопрос не столько в API, сколько в качестве того, что получилось, что будет доступно в конкретном компиляторе и как это все будет меняться при смене версии компилятора.
Библиотека работы с сетью, мне кажется, вообще ничего не требует от компилятора.
S>Когда приложение завязано на внешнюю библиотеку, а не на stdlib все как-то проще. Взял условный Asio-1-32-0 и сидишь с ним пока все устраивает. А если и нашел ошибку, то можно сперва ее в своем форке исправить, патч в апстрим закинуть и все. Тогда как при обнаружении проблем с поведением условного std::net::tcp::socket на конкретной платформе хз как быть.
Здравствуйте, netch80, Вы писали:
N>Библиотека работы с сетью, мне кажется, вообще ничего не требует от компилятора.
Вроде как std::from_chars тоже ничего не требует от компилятора. Но еще совсем недавно можно было нарваться на компилятор, где from_chars не было.
S>>Когда приложение завязано на внешнюю библиотеку, а не на stdlib все как-то проще. Взял условный Asio-1-32-0 и сидишь с ним пока все устраивает. А если и нашел ошибку, то можно сперва ее в своем форке исправить, патч в апстрим закинуть и все. Тогда как при обнаружении проблем с поведением условного std::net::tcp::socket на конкретной платформе хз как быть.
N>Это проблема с любым рантаймом, вам не кажется?
Одно дело когда в рантайме сломана, например, раскрутка стека при выбросе исключения.
Другое дело, когда в конкретной версии условного VC++ неправильно отрабатывает условный socket.set_option или ip::address::from_string.
По крайней мере с моей колокольни это видится так.
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, быть примерно так же, как и с модулями. LVV>Потихоньку пробовать и вводить в некоторых местах...
Ни разу не слышал о хотя бы поползновениях применять их (в европейской IT индустрии). Не взлетит.
LVV>>Ну, быть примерно так же, как и с модулями. LVV>>Потихоньку пробовать и вводить в некоторых местах... S>Ни разу не слышал о хотя бы поползновениях применять их (в европейской IT индустрии). Не взлетит.
Думаете модули в С++ — мертворожденное дитя ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
N>>Библиотека работы с сетью, мне кажется, вообще ничего не требует от компилятора. S>Вроде как std::from_chars тоже ничего не требует от компилятора. Но еще совсем недавно можно было нарваться на компилятор, где from_chars не было.
Отсутствие и неработа — разные случаи.
S> Тогда как при обнаружении проблем с поведением условного std::net::tcp::socket на конкретной платформе хз как быть.
N>>Это проблема с любым рантаймом, вам не кажется?
S>Одно дело когда в рантайме сломана, например, раскрутка стека при выбросе исключения. S>Другое дело, когда в конкретной версии условного VC++ неправильно отрабатывает условный socket.set_option или ip::address::from_string.
S>По крайней мере с моей колокольни это видится так.
Ну это, по крайней мере, не запретит использовать свою библиотеку или прямые вызовы ядерного API.
Здравствуйте, Великий Мессия, Вы писали:
ВМ>... SaZ>>Вот интересно, а почему тогда не депрекейтнули std::bit_cast? Вроде как он теперь не нужен?
ВМ>нужен ВМ>bit_cast побитово копирует в новый тип ВМ>а start_lifetime_as конструирует и возвращает указатель
Это всё понятно, но тут два момента: в каких случаях теперь нужен bit_cast, когда можно сделать start_lifetime_as и просто скопировать? И второе — имхо, название неудачное, какой-нибудь bit_copy более явно отразил бы суть.
Здравствуйте, LaptevVV, Вы писали:
BFE>>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку. LVV>Ну, есть же модель OSI LVV>Там есть tcp/ip и udp
К C++ это какое имеет отношение?
LVV>И фактический стандарт — сокеты. LVV>Я не в курсе — сокеты в nix-системах стандартизированы официально ? LVV>На уровне API Linux — фактически да.
Опять же сокеты — чего в них хорошего? Неужели лучше ничего нельзя придумать? Не верю.
BFE>>>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>>>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку. LVV>>Ну, есть же модель OSI LVV>>Там есть tcp/ip и udp BFE>К C++ это какое имеет отношение?
Ну дык я понял, что отдельный стандарт — это об общих принципах сетевой модели. LVV>>И фактический стандарт — сокеты. LVV>>Я не в курсе — сокеты в nix-системах стандартизированы официально ? LVV>>На уровне API Linux — фактически да. BFE>Опять же сокеты — чего в них хорошего? Неужели лучше ничего нельзя придумать? Не верю.
Ну, придумай. Зачем ждать милостей от природы ?
Сокеты, насколько мне известно, придумал Кен Томпсон для берколеевской версии юникса еще году в 1981-1983 примерно...
Они прекрасно отделяют клиента от сервера.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, netch80, Вы писали:
N>>>Библиотека работы с сетью, мне кажется, вообще ничего не требует от компилятора. S>>Вроде как std::from_chars тоже ничего не требует от компилятора. Но еще совсем недавно можно было нарваться на компилятор, где from_chars не было.
N>Отсутствие и неработа — разные случаи.
Если человек разрабатывал программу на компиляторе X, перешел на компилятор Y, а там нет from_chars, то есть ли разница между отсутствием и неработой?
Ну и я не очень понимаю что вы мне пытаетесь донести. Примеры с std::format и std::from_chars говорят о том, что без приключений новое не появляется.
Я еще помню времена стандартизации С++98, когда в каком-то компиляторе какой-то класс из STL соответствует стандарту, а в другом -- еще нет.
Уверен, что с std::net будет в точности тоже самое.
Вы хотите сказать, что теперь-то все окажется иначе?
N>Ну это, по крайней мере, не запретит использовать свою библиотеку или прямые вызовы ядерного API.
Оттож. Тот же Asio я могу использовать прямо сейчас, не дожидаясь прекрасного свелого будущего.
И даже когда оно наступит, то какой смысл переделывать то, что будет за это время сделано на Asio? Полагаю, что никакого.
А если так, то и незачем тратить ресурсы впустую. И даже не впустую, а взваливая груз на будущих мейнтенеров будущей стандартной библиотеки С++.
LVV>>Ну, придумай. Зачем ждать милостей от природы ? LVV>>Сокеты, насколько мне известно, придумал Кен Томпсон для берколеевской версии юникса еще году в 1981-1983 примерно... LVV>>Они прекрасно отделяют клиента от сервера.
BFE>Во-первых, задач много, а я один. BFE>Во-вторых, всё уже вроде бы придумано. BFE>Я точно помню, что читал статью, в которой рассказывалось о разработке технологии коммуникации на основе обмена буферами данных, то есть без копирования. Быстрый поиск вывел меня на статью BFE>wikipedia Zero-copy. Если уж стандартизировать, то что-то передовое, а не полувековой давности технологию.
Интересно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>и только сейчас MS оптимизировал свою самую медленную
M>Может, и медленные, зато не падают, как в GCC, на длинных строках
слезай со старых компиляторов со старым древним stl
Здравствуйте, Великий Мессия, Вы писали:
ВМ>для модулей нужен минимум С++20
На С++20 проектов вагон и маленькая тележка, но модули не использует никто.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>модули это бомбезная штука
S>А что именно в них бомбезное?
если не брать базовые вещи типа скорость компиляции, не просачивание мусора по TU
то для меня, облегчает чтение кодовой базы
разбираясь/читая большие С++/C/rust/java проекты
rust/java читаются легче из за того что весь скажем TU в одном файле
в отличии от C/C++ где постоянно нужно держать контекст хидера и имплементации в уме
а если они еще по разным директориям то это жуть
ну да, можно и в модулях такого наговнокодить
или по старинке все в прекомпаил хидеры запихать как в бусте
но все же модули заставляет более структурно подходить к разработке
Здравствуйте, Великий Мессия, Вы писали:
S>>А что именно в них бомбезное?
ВМ>если не брать базовые вещи типа скорость компиляции
Ну почему же не брать. Это же одна из киллер фич, под флагом которой это сраное говно в стандарт подтаскивали.
И какой результат по скорости?
Вот у меня есть возможность сравнить скорость компиляции относительно небольшого C++ного проекта на 100KLOC не считая зависимостей (а в зависимостях там и Boost, и Asio, и Folly, и Glaze).
На старом ноутбуке 2019-го года с i7-8550U и относительно новом на Ryzen 7 8845H 2024-го.
На Ryzen проект собирается в четыре раза быстрее.
Без модулей и вообще какой либо переделки кодовой базы.
Тупо рост скоростей CPU, RAM и SSD дало прирост в разы за пять лет.
Те самые пять лет, что хитровывернутые модули, придуманные инопланетянами с Нибиру, есть в стандарте, но все никак не могут быть нормально реализованными во всей большой тройке компиляторов. За пять, мать его, лет, Карл!
В том числе прирост скорости обеспечивается и возможностью запустить компиляцию не в четыре потока, как на i7-8550U, а восемь.
А еще через пару тройку лет можно будет запускать и в 16 потоков на обычных офисных ноутбуках, даже не игровых. Не говоря уже про десктопы с полноценными процессорами.
А лет через пять -- и в 32 потока.
И все это без переделки кодовых баз, которым уже не по одному десятку лет.
Причем, что важно, код в стиле "Си с классами" сейчас компилируется просто влет, меньше секунды на .cpp файл.
А вот код в стиле современного C++ с трех-четырех этажными шаблонами, Boost-ом, Folly и вот этим вот всем, как компилировался десятки секунд, так и компилируется. Причем по показаниям от GCC/clang-а на парсинг заголовочных файлов там уходит, максимум, 1/3 общего времени. Максимум. Все остальное -- это инстанциирование шаблонов и их оптимизация. Т.е. то, что в таком же виде останется и с модулями.
Т.е. даже если эту 1/3 времени сократят, скажем, раза в три, то вместо 30 секунд на компиляцию одного .cpp-файла со сложными шаблонами внутри, у меня будет уходить 22 секунды. Может быть даже 20.
Ну ахринеть выигрыш. Платить за который нужно будет тем, что рано или поздно мне лично придется переводить под модули десятки (если не сотни) тысяч строк кода. Только и остается, что поклониться в ноги и сказать комитету большое спасибо, удружили так удружили.
Вот только кроме него никто за столько лет так и не осилил написать какую-нибудь более менее приличную библиотеку для работы с сетью на С++. Хотя разговоров всегда было очень много.
ВМ>и известный фалько, предлагает форкнуть asio
Чем в очередной раз обсуждать, взяли бы, форкнули, и сделали бы как считают нужным, глядишь и сам автор Asio бы зашевелился, может быть внедрил себе что-то из форка, пошла бы движуха и развитие.
А если бы реально сделали какую-нибудь новую моложежную библиотеку с немного другой архитектурой тоже было бы отлично, было бы у нас две библиотеки с немного разными подходами, можно было бы спорить о том, что где лучше сделано, перетаскивать удачные решения из одной библиотеки в другую, опять же движуха и развитие.
Что бы кто там ни обсуждал, у Asio нет конкурентов, их просто реально нет, никто не готов взять на себя такую библиотку а вот обсуждают необходимость работы с сетью в С++ десятилетиями уже.
Здравствуйте, Великий Мессия, Вы писали:
N>>Или тупо устал и подвыгорел? При 20+ годах работы вполне вероятно.
ВМ>он комитит в репу ВМ>принимает к сведению и иногда реагирует на иссуес ВМ>но в дискуссии не вступает
Не любит с людьми общаться? Может он просто глубокий интроверт?
ВМ>начинают с форка ВМ>а в рассуждениях заходят за написание нового ВМ>с новым дизайном
Помню, был форк emacs-а. Несколько лет emacs и xemacs жили своей собственной жизнью, потом вроде слились. То же самое, X11 и Xorg.
Форк — не обязательно переписывание. По-разному бывает.
Здравствуйте, B0FEE664, Вы писали:
BFE>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку.
А смысл? Получится-то подмножество POSIX. А POSIX уже есть...
Здравствуйте, so5team, Вы писали:
S>А вот когда функциональность по работе с сетью завязана, условно, на установку опции nodelay для сокета, и на одном компиляторе эта опция уже есть, тогда как на другом -- нет, вот тут все будет гораздо веселее.
А есть еще нюансы реализации на уровне ОС. Например, в Linux установка опции nodelay немедленно отправляет в сеть все уже накопленные в сокете но еще не отправленные данные. Поэтму можно работать в стиле "сняли nodelay, отправили несколько кусочков данных порознь, установили nodelay, все данные и улетели". А в BSD установка nodelay влияет только на следующий send. Поэтому если по каким-то причинам не получается генерировать разом все кусочки данных, придётся городить буфер в user space. И универсального решения тут нет, потому, что одно дело, когда траффик маленький, но Nagle мешает, а другое дело, когда трафик большой, и лишняя буферизация — это заметные накладные расходы.
LVV>>Ну, есть же модель OSI LVV>>Там есть tcp/ip и udp Pzz>Там API не определён. Pzz>Ну и мой любимый вопрос, к какому уровню OSI относится тунелирование IP-трафика через HTTP?
Стесняюсь спросить: и к какому ? LVV>>И фактический стандарт — сокеты. LVV>>Я не в курсе — сокеты в nix-системах стандартизированы официально ? Pzz>Да, но есть нюансы. Pzz>На уровне "открыть TCP-сокет и куда-нибудь приконнектиться" всё более-менее одинаковое. А вот на уровне "получить список сетевых интерфейсов", "получить список локальных IP-адресов", "узнать, через какой интерфейс уйдёт пакет, если послать его по адресу N", на уровне UDP-мултикастинга системы расходятся. Не то, чтобы совсем уж в разные стороны, но заметно. Pzz>А есть еще более интересные уровни. Например, "получить UID процесса, который приконнектился к нашему локальному серверу через loopback" — тут уж совсем системно-зависимые дебри.
Вот. Приеду в Москву — можно об этом будет поговорить и обсудить.
Мне надо же как-то сетевое программирование студням преподавать.
На уровне Стивенса и сокетов — понятно.
А потом начинаются разные варианты...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
Pzz>>Ну и мой любимый вопрос, к какому уровню OSI относится тунелирование IP-трафика через HTTP? LVV>Стесняюсь спросить: и к какому ?
Вот мне и самому интересно. Вроде как это надстройка над прикладным протоколом, HTTP, с одной стороны. С другой стороны, торчит из него IP level, т.е., 3, довольно таки низкий.
Я это к тому, что академические модели, типа OSI, конечно дают полезную общепринятую терминологию. Но реальная жизнь не очень укладывается в эту красивую картинку.
Pzz>>А есть еще более интересные уровни. Например, "получить UID процесса, который приконнектился к нашему локальному серверу через loopback" — тут уж совсем системно-зависимые дебри. LVV>Вот. Приеду в Москву — можно об этом будет поговорить и обсудить. LVV>Мне надо же как-то сетевое программирование студням преподавать. LVV>На уровне Стивенса и сокетов — понятно. LVV>А потом начинаются разные варианты...
Второй год уже обещаешь понаехать в Москву. Я уж соскучался даже
...
K>Что бы кто там ни обсуждал, у Asio нет конкурентов, их просто реально нет, никто не готов взять на себя такую библиотку а вот обсуждают необходимость работы с сетью в С++ десятилетиями уже.
их вагон и маленькая тележка тех либ
весь гитхаб забит
даже фб свою написала, даже дуров свою написали итд, их килотонны
но все равно некие полухины из яндекса пилят свой userver в котором своя сетевая либа
вот это я реально понять не могу
LVV>>Вот. Приеду в Москву — можно об этом будет поговорить и обсудить. LVV>>Мне надо же как-то сетевое программирование студням преподавать. LVV>>На уровне Стивенса и сокетов — понятно. LVV>>А потом начинаются разные варианты... Pzz>Второй год уже обещаешь понаехать в Москву. Я уж соскучался даже
В 24 году была операция — пришлось отменить вообще все.
В 25 году — только в последнюю неделю удалось вырваться в Липецк и в Воронеж. 25 приехал, 29 уехал — никак в Москву не попадал.
В Воронеже обещались в декабре на конференцию позвать. Но пока телодвижений не сделали.
А я тут по самые помидоры занят и в вузе и не в вузе...
Еще у меня 31.01 — 12.02 отпуск. Если здоровье позволит — приеду.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Великий Мессия, Вы писали:
ВМ>- сеть не нужно
Сеть в стандартной библиотеке С++ не нужна так же, как там не был нужен XML, и так же, как там сейчас не нужны JSON/YAML/TOML и прочие популярные на данный момент технологии. Это все прекрасно обеспечивается внешними библиотеками.
А если в языке по его природе есть препятствия к тому, чтобы легко подключать в проект внешние библиотеки, то нужно устранять эти препятствия, а не пытаться затащить все в стандартную библиотеку.
Вот был бы C++ языком одной корпорации (как Java у Sun/Oracle, C# у Microsoft, Go у Google или даже Rust у Mozilla), чтобы была всего одна референсная реализация, тогда можно было бы рассматривать вариант "жирной" стандартной библиотеки у C++. Но не в условиях С++а, когда даже у той же Microsoft не хватает ресурсов на развитие VC++.
ВМ>- модули не нужны
Модули не нужны потому, что они вносят раскол в язык по типу того, что было в Python-е после выхода Python3. Раскол длиной в десятилетие, а то и больше. С сомнительными положительными последствиями, поскольку, на мой взгляд:
— сами по себе модули в C++ получились переусложненными. Такую заумную хрень еще нужно было придумать. Кто-то, видимо, очень старался. Причем эти "кто-то" вероятно, родились сильно после выхода Turbo Pascal 5.0, ибо если знать про систему unit-ов Turbo Pascal-я и предшествующих им модулей из Modula-2, то вряд ли бы у вменяемых людей поднялась рука предлагать хитровывернутые модули из C++20;
— внедряя модули отклонили идею "эпох"/"поколений" для C++. Чтобы в начале модуля можно было указать к какой "эпохе" относится код внутри модуля. Тем самым можно было бы наметить путь к постепенному отказу от самого одиозного наследия чистой Сишечки в C++. Например, внутри модулей в рамках, скажем, "эпохи 2025.01" можно было бы запретить неявные сужающие преобразования. И т.д., и т.п.
Т.е. мало того, что заложили свинью тем, что рано или поздно придется заниматься трансформацией легаси под модули, так еще и сами модули сделали такими, что без слез не взглянешь.
ВМ>- комитет занимается не тем чем надо
Люди ошибаются. Комитет состоит из людей. Значит и комитет может ошибаться. Чему уже были подтверждения в виде тех же export template.
ВМ>как вы только уживаетесь со своим Альтер его, которое на лоре рассказывает про то какой классный С++26
Судя по уровню вашего умственного развития, которое не позволило вам усвоить зачем нужны заглавные и строчные буквы, вы, скорее всего, просто не понимаете написанного. Ибо нигде я не рассказывал о том, какой классный C++26.
Здравствуйте, Великий Мессия, Вы писали:
ВМ>Здравствуйте, ksandro, Вы писали:
ВМ>...
K>>Что бы кто там ни обсуждал, у Asio нет конкурентов, их просто реально нет, никто не готов взять на себя такую библиотку а вот обсуждают необходимость работы с сетью в С++ десятилетиями уже.
ВМ>их вагон и маленькая тележка тех либ ВМ>весь гитхаб забит ВМ>даже фб свою написала, даже дуров свою написали итд, их килотонны
Все эти библиотеки делятся на 2 типа: 1) поделки, написанные с разной степенью профессионализма 2) большие фреймворки заточенные для довольно высокоуровневых задач (например для веб сервисов).
Asio это низкоуровневая оберертка над сокетами, и кроссплатформенные абстракции над асинхронным вводом/выводом. Я не знаю пока более менее популярных аналогов. Я бы очень хотел видеть конкурирующую профессионально написанную библиотеку, не поделку и не фреймворк. Возможно я просто не знаю современных тенденций, буду рад, если народ накидает мне тут ссылки на хорошие библиотеки, конкуренты Asio.
ВМ>но все равно некие полухины из яндекса пилят свой userver в котором своя сетевая либа ВМ>вот это я реально понять не могу
В том то и проблема, что сейчас часто проще написать свою библиотеку, для своих целей, Asio все-таки не слишком удобна.
К сожалению userver тяжелый и не кроссплатформенный фреймворк, работа с сетью в него вшита, если бы они выделили свою сетевую библиотеку в отдельный проект, а бы с удовльствием на нее взглянул, уверен, что там все сделанно очень профессионально. Но тянуть в прект весь Userver, если нужен простой TCP клиент, как-то нет желания.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>- сеть не нужно
S>Сеть в стандартной библиотеке С++ не нужна так же, как там не был нужен XML, и так же, как там сейчас не нужны JSON/YAML/TOML и прочие популярные на данный момент технологии. Это все прекрасно обеспечивается внешними библиотеками.
сеть не нужна
мутексы не нужны
треиды не нужны
контейнеры не нужны
строки не нужны
атомики не нужны
итд
есть куча внешний библиотек
тот же буст, ага
сеть нужна
ее просили как минимум в опросах комитета которые проходят каждый год
и выбор asio как интерфейса вполне очевиден
это единственная либа для работы сетью которая прожила столько времени
хотя свою славу я считаю она обрела именно будучи в бусте а не отдельно
но если рассматривать под вашим углом о не нужности
я бы предпочел о разделения стандарта на язык и его библиотеку
это помогло бы выходить стандарту библиотеки в два раза чаще стандарта языка
тогда сеть и экзекуторы можно было бы уже впихнуть в любой стандартную библиотеку
между С++23 и С++26
S>А если в языке по его природе есть препятствия к тому, чтобы легко подключать в проект внешние библиотеки, то нужно устранять эти препятствия, а не пытаться затащить все в стандартную библиотеку.
нужно удобное подключение уже существующих библиотек — ага
что бы каждый мог подключить свою шикарную реализацию строк
а при смене работодателя тратить время на изучения оной
да и вообще всех новых либ
S>Вот был бы C++ языком одной корпорации (как Java у Sun/Oracle, C# у Microsoft, Go у Google или даже Rust у Mozilla), чтобы была всего одна референсная реализация, тогда можно было бы рассматривать вариант "жирной" стандартной библиотеки у C++. Но не в условиях С++а, когда даже у той же Microsoft не хватает ресурсов на развитие VC++.
если так смотреть, то не только у MS не хватает ресурсов, или все же не в ресурсах дело
а возвращаясь к сказанному ранее, разрыв такта по времени, в выходе стандарта и его реализациях в компиляторах
ВМ>>- модули не нужны
S>Модули не нужны потому, что они вносят раскол в язык по типу того, что было в Python-е после выхода Python3. Раскол длиной в десятилетие, а то и больше. С сомнительными положительными последствиями, поскольку, на мой взгляд:
модули нужны на мой взгляд
и нужно было их внедрять Страуструпу еще на начальном этапе, вместе с рефлексией и концептами
тогда бы возможно не появился раст а ВандервудАлександреску не изобретал lang D
S>- сами по себе модули в C++ получились переусложненными. Такую заумную хрень еще нужно было придумать. Кто-то, видимо, очень старался. Причем эти "кто-то" вероятно, родились сильно после выхода Turbo Pascal 5.0, ибо если знать про систему unit-ов Turbo Pascal-я и предшествующих им модулей из Modula-2, то вряд ли бы у вменяемых людей поднялась рука предлагать хитровывернутые модули из C++20;
Вандервуд обкатал эту идею в своем lang D
и он был насколько я помню инициатором пропозла про модули
инициатором модулей был Вандервуд
S>- внедряя модули отклонили идею "эпох"/"поколений" для C++. Чтобы в начале модуля можно было указать к какой "эпохе" относится код внутри модуля. Тем самым можно было бы наметить путь к постепенному отказу от самого одиозного наследия чистой Сишечки в C++. Например, внутри модулей в рамках, скажем, "эпохи 2025.01" можно было бы запретить неявные сужающие преобразования. И т.д., и т.п.
в синтаксис модулей? это асбурд
модули не заменяют а дополняют, не нравится пишите без модулей
а то тогда и в обычные файлы нужна эпоха, что бы можно было отказываться от сишечки
S>Т.е. мало того, что заложили свинью тем, что рано или поздно придется заниматься трансформацией легаси под модули, так еще и сами модули сделали такими, что без слез не взглянешь.
тяжело консерваторам, понимаю
ВМ>>- комитет занимается не тем чем надо
S>Люди ошибаются. Комитет состоит из людей. Значит и комитет может ошибаться. Чему уже были подтверждения в виде тех же export template.
но почему вы только здесь решили об этом рассказать?
у обычных пользователей есть возможность если не влиять на развитие языка, то пытаться это делать
я пытаюсь, где то мимо, где как мне кажется получается/получилось
вот не смотря на то что мне не нравится ни сеть которую приняли, ни экзекуторы
это лучше чем ничего
ВМ>>как вы только уживаетесь со своим Альтер его, которое на лоре рассказывает про то какой классный С++26
S>Судя по уровню вашего умственного развития, которое не позволило вам усвоить зачем нужны заглавные и строчные буквы, вы, скорее всего, просто не понимаете написанного. Ибо нигде я не рассказывал о том, какой классный C++26.
возьмите в кавычки "классный С++26"
имелось ввиду что на лоре я не замечал от вас какой то критики по С++, скорее наоборот
а последние ваши ответы там были про С++26 и точно не о его критике
Здравствуйте, Великий Мессия, Вы писали:
S>>Сеть в стандартной библиотеке С++ не нужна так же, как там не был нужен XML, и так же, как там сейчас не нужны JSON/YAML/TOML и прочие популярные на данный момент технологии. Это все прекрасно обеспечивается внешними библиотеками.
ВМ>сеть не нужна ВМ>мутексы не нужны ВМ>треиды не нужны ВМ>контейнеры не нужны ВМ>строки не нужны ВМ>атомики не нужны
Великий Мессия тоже не нужен, из-за тупости.
В стандартной библиотеке должны быть т.н. vocabulary types, вроде строк, контейнеров, атомиков.
Но вот даже к тредам в стандартной библиотеке уже есть вопросы. Например, как ограничить размер стека для нового треда? Как менять приоритет для треда?
С++ -- это такой специфический язык, который сейчас нужен далеко не везде, а там, где он еще нужен, требуется контроль и, зачастую, прямая интеграция с возможностями конкретной платформы. Это уже даже на уровне std::thread видно. А в библиотеке для работы с сетью такой специфики будет еще больше.
Кроме того, для программирования на С++ нужны и другие вещи. Например, средства для работы с аргументами командной строки. Или средства для логирования. Или самые простые средства для криптографии (чтобы можно было хотя бы sha1 или sha512). И что, все это теперь тянуть в стандарт?
ВМ>сеть нужна
Далеко не всегда и далеко не всем.
ВМ>ее просили как минимум в опросах комитета которые проходят каждый год
В свое время очень многим был нужен XML.
А вообще, вспоминается (емнип) Генри Форд, который сказал: "Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь."
ВМ>нужно удобное подключение уже существующих библиотек — ага ВМ>что бы каждый мог подключить свою шикарную реализацию строк
В проекте у текущего заказчика, как бы это не было смешно, используется три типа обычных векторов: std::vector, folly::fbvector и еще один самописный, потому что стандартный не подошел под специфический сценарий.
Проект стартовал в 2024-го без какого-либо легаси, тем не менее в него по разным причинам пришлось затащить и другие типы векторов, и другие типы ассоциативных контейнеров, т.к. классы из stdlib не тянули в конкретных условиях.
Повторюсь, C++ -- это сейчас очень специфический язык. Если кому-то нужно наговнякать без оглядки на скорость/ресурсоемкость/предсказуемость, то есть куча более безопасных языков с жирными стандартными библиотеками.
ВМ>и нужно было их внедрять Страуструпу еще на начальном этапе
Да, это было единственное хорошее время, когда модули могли бы внедрить.
Но раз этого не сделали тогда, то сейчас это уже очень и очень неоднозначное решение.
От которого больше вреда, чем пользы.
ВМ>вместе с рефлексией и концептами
Ага, все это в 1985-ом году, когда Страуструп еще сам не знал как у него в языке будут шаблоны выглядеть.
ВМ>тогда бы возможно не появился раст а Вандервуд не изобретал lang D
Язык D изобрел Вальтер Брайт.
ВМ>Вандервуд обкатал эту идею в своем lang D
Насколько я помню, изначально было два предложения -- одно от Microsoft, второе от Google.
И делалось каждое предложение под то, кому как удобнее свои кодовые базы переводить под модули -- у Microsoft-а было свое представление о прекрасном, у Google -- свое.
А потом, когда в комитете ни одно из них не смогло победить, решили скрестить бульдога с носорогом.
S>>- внедряя модули отклонили идею "эпох"/"поколений" для C++. Чтобы в начале модуля можно было указать к какой "эпохе" относится код внутри модуля. Тем самым можно было бы наметить путь к постепенному отказу от самого одиозного наследия чистой Сишечки в C++. Например, внутри модулей в рамках, скажем, "эпохи 2025.01" можно было бы запретить неявные сужающие преобразования. И т.д., и т.п.
ВМ>в синтаксис модулей? это асбурд
Повторюсь, Великий Мессия -- идиот.
ВМ>модули не заменяют а дополняют
Модули вводят новый контекст, в котором код гарантированно будет соответстовать C++20.
Т.е. как только в исходнике появляется "шапка" с ключевым словом "module", так сразу становится понятно, что код ниже адаптирован под C++20.
Что принципиально отличает модули от произвольных .hpp/cpp-файлов, в которых может быть код еще до C++98 времен.
А раз так, то можно в декларацию модуля тем или иным образом добавить "эпоху".
Это дело, емнип, даже комитетом обсуждалось. Но, к сожалению, не было принято. Экзекуторы же и сеть нужнее, ага.
ВМ>не нравится пишите без модулей
Так и делаю. И планирую в продолжать в ближайшие пару лет.
ВМ>а то тогда и в обычные файлы нужна эпоха, что бы можно было отказываться от сишечки
В обычные файлы это добавлять сложнее.
S>>Т.е. мало того, что заложили свинью тем, что рано или поздно придется заниматься трансформацией легаси под модули, так еще и сами модули сделали такими, что без слез не взглянешь.
ВМ>тяжело консерваторам, понимаю
Не понимаете. И не консерваторам, а тем, кто не любит искуственной сложности на ровном месте.
ВМ>но почему вы только здесь решили об этом рассказать?
Я об этом рассказываю везде (например).
ВМ>вот не смотря на то что мне не нравится ни сеть которую приняли, ни экзекуторы ВМ>это лучше чем ничего
А у меня обратная точка зрения: чем говно, да еще в говняной упаковке (это я сейчас в первую очередь про модули), так лучше ничего.
ВМ>возьмите в кавычки "классный С++26"
Как и ожидалось, никаких рассказов про "классный C++26" не было.
ВМ>имелось ввиду что на лоре я не замечал от вас какой то критики по С++, скорее наоборот ВМ>а последние ваши ответы там были про С++26 и точно не о его критике
В C++ много хорошего. Например, концепты и operator<=>. За это комитету огромное спасибо.
А если кто-то чего-то про C++ не знает, или не понимает, то почему бы не поделиться своими скудными знаниями.
Или развенчать какие-то мифы.
Но если мне кажется, что комитет подкладывает свинью, то не вижу смысла делать вид, что это божья роса.
как я говорил, строить лесенки в темах не люблю
не используйте модули
они вам явно не подходят
продолжайте дальше восхвалять С++
что бы со стороны не казалось что у вас раздвоение личности
адью в этой теме
Здравствуйте, Pzz, Вы писали:
Pzz>Вот мне и самому интересно. Вроде как это надстройка над прикладным протоколом, HTTP, с одной стороны. С другой стороны, торчит из него IP level, т.е., 3, довольно таки низкий. Pzz>Я это к тому, что академические модели, типа OSI, конечно дают полезную общепринятую терминологию. Но реальная жизнь не очень укладывается в эту красивую картинку.
Ой блин.
Вот тот же МЭКовский баян, у которого внтури ISO 9506.
Там вот прямо все 7 уровней. И session и presentation и прочия.
Только вот работает оно в примерно 100% инсталляций, будучи завернутым в TCP/IP, и вся эта требуха просто сидит мертвым грузом внутри пакетов и жрет ресурсы.
Здравствуйте, LaptevVV, Вы писали:
BFE>>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку. LVV>Ну, есть же модель OSI LVV>Там есть tcp/ip и udp
В модели OSI нет ни TCP, ни TCP/IP, ни UDP. Если про строгую OSI, то там свои протоколы чуть более чем полностью.
Ну да, текущие сети реюзают L1-L2, как IEEE802, и то с особенностями. Например, честный IEEE802.2 требует, чтобы была длина пакета, а в текущих IP сетях там не длина, а тип (0x0800 — IPv4, 0x0806 — ARP, 0x86ED — IPv6), это называется Ethernet II, а не IEEE802.2. Но все привыкли. SAP/SNAP навороты над этим уровнем давно забыты.
Если говорить про модель OSI как учебную модель для первичного понимания, то да, в этом смысле она продолжает быть полезной. Рассказать про 7 уровней и связи между ними, а после этого вводить в реальный мир, где, например, повторения последовательностей с инверсией между ними — в случае туннелирования любого вида (хоть GRE, хоть WireGuard, хоть HTTPS).
Разницу в верхних уровнях мало кто понимает. Например, вики пишет, что HTTP это уровень 7, хотя основная нагрузка у него на уровне 5 (сеансовом). Ну при том, что в TCP/IP это всё один уровень I, это мало кого волнует.
В протоколах OSI есть некоторое количество полезностей, которые не перешли в TCP/IP. Например, там изначально вместо TCP был аналог SCTP с делением на сообщения, что помогало от типовых индусских проблем "один send — один recv". Но сейчас и это маловажно, даже в IoT переползают на фрейминг HTTP/DTLS/QUIC/etc.
LVV>И фактический стандарт — сокеты. LVV>Я не в курсе — сокеты в nix-системах стандартизированы официально ? LVV>На уровне API Linux — фактически да.
На это я уже отвечал ссылкой на POSIX.
К сожалению, много важных расширенных возможностей туда не попали. Но их и так используют единицы процентов от всего софта.
