Здравствуйте, Великий Мессия, Вы писали:
ВМ>в целом проблема здесь другая
Проблема здесь та, что есть С++ "на бумаге", а есть C++ "в компиляторе". И в обычной жизни это две большие разницы.
Когда в каком-то компиляторе нет std::start_lifetime_as, даже если компилятор имеет ключик -std=c++23, то это дело еще можно какими-то собственными функциями-заглушками обойти.
А вот когда функциональность по работе с сетью завязана, условно, на установку опции nodelay для сокета, и на одном компиляторе эта опция уже есть, тогда как на другом -- нет, вот тут все будет гораздо веселее.
Ну и чем больше распухает стандарт (особенно в части stdlib), тем дольше будет путь от С++ "на бумаге" до C++ "в компиляторе".
Вот ейбоху комитет бы лучше озадачился стандартом описания зависимостей для C++ проекта. Чтобы vcpkg/conan/etc могли понимать этот стандарт и подтаскивали бы к проекту то, что требуется. Тогда обычный человек в два клика мог подключить к себе в проект конкретную версию Asio или POCO, и делал бы работу с сетью как ему хочется/нравится. Не дожидаясь включения std::networking в C++29 с реализацией в 2033-ем году.
Здравствуйте, 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? Вроде как он теперь не нужен?
Здравствуйте, Великий Мессия, Вы писали:
ВМ>будет на всех компиляторах
Когда (и если) будет, тогда и поговорим.
Пока же есть пример с std::format.
Если проект начался до включения std::format в стандарт и использовал fmtlib, то смысла переходить в проекте на std::format нет.
Если проект начался с std::format, но потом вынужден был пойти на платформу/компилятор, где std::format еще нет (реальность, увы), то проще выбросить std::format в пользу fmt::format и дальше оставаться на fmtlib.
Может лет через 5 ситуация будет другая, но пока fmtlib выглядит предпочтительнее std::format.
Есть сильные подозрения, что касательно std::net будет аналогично. Что наводит на мысль, что таки не нужно лохматить бабушку и пытаться втащить std::net в стандарт.
Здравствуйте, 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? Полагаю, что никакого.
А если так, то и незачем тратить ресурсы впустую. И даже не впустую, а взваливая груз на будущих мейнтенеров будущей стандартной библиотеки С++.
Здравствуйте, LaptevVV, Вы писали:
BFE>>>>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>>К C++ это какое имеет отношение? LVV>Ну дык я понял, что отдельный стандарт — это об общих принципах сетевой модели.
POSIX определяет API в виде деклараций функций на языке C. При этом сам стандарт языка Си — это отдельный стандарт, включающий в себя библиотеку языка Си.
Соответственно, я не вижу причин, почему бы не быть стандарту в виде деклараций классов на С++, которые могут использоваться для сетевого взаимодействия и которые не входят в стандарт языка С++.
BFE>>Опять же сокеты — чего в них хорошего? Неужели лучше ничего нельзя придумать? Не верю. LVV>Ну, придумай. Зачем ждать милостей от природы ? LVV>Сокеты, насколько мне известно, придумал Кен Томпсон для берколеевской версии юникса еще году в 1981-1983 примерно... LVV>Они прекрасно отделяют клиента от сервера.
Во-первых, задач много, а я один.
Во-вторых, всё уже вроде бы придумано.
Я точно помню, что читал статью, в которой рассказывалось о разработке технологии коммуникации на основе обмена буферами данных, то есть без копирования. Быстрый поиск вывел меня на статью wikipedia Zero-copy. Если уж стандартизировать, то что-то передовое, а не полувековой давности технологию.
LVV>>Ну, придумай. Зачем ждать милостей от природы ? LVV>>Сокеты, насколько мне известно, придумал Кен Томпсон для берколеевской версии юникса еще году в 1981-1983 примерно... LVV>>Они прекрасно отделяют клиента от сервера.
BFE>Во-первых, задач много, а я один. BFE>Во-вторых, всё уже вроде бы придумано. BFE>Я точно помню, что читал статью, в которой рассказывалось о разработке технологии коммуникации на основе обмена буферами данных, то есть без копирования. Быстрый поиск вывел меня на статью BFE>wikipedia Zero-copy. Если уж стандартизировать, то что-то передовое, а не полувековой давности технологию.
Интересно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
