Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>и только сейчас MS оптимизировал свою самую медленную
M>Может, и медленные, зато не падают, как в GCC, на длинных строках
слезай со старых компиляторов со старым древним stl
Здравствуйте, 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
Здравствуйте, Великий Мессия, Вы писали:
ВМ>для модулей нужен минимум С++20
На С++20 проектов вагон и маленькая тележка, но модули не использует никто.
Здравствуйте, 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 лет
что бы новые проекты изначально начали писать на них
и желание разрабов старого легаси переводить на модули
Здравствуйте, 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 нет конкурентов, их просто реально нет, никто не готов взять на себя такую библиотку а вот обсуждают необходимость работы с сетью в С++ десятилетиями уже.
Здравствуйте, 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 конверций как в расте
Здравствуйте, Великий Мессия, Вы писали:
N>>Или тупо устал и подвыгорел? При 20+ годах работы вполне вероятно.
ВМ>он комитит в репу ВМ>принимает к сведению и иногда реагирует на иссуес ВМ>но в дискуссии не вступает
Не любит с людьми общаться? Может он просто глубокий интроверт?
ВМ>начинают с форка ВМ>а в рассуждениях заходят за написание нового ВМ>с новым дизайном
Помню, был форк emacs-а. Несколько лет emacs и xemacs жили своей собственной жизнью, потом вроде слились. То же самое, X11 и Xorg.
Форк — не обязательно переписывание. По-разному бывает.
Здравствуйте, B0FEE664, Вы писали:
BFE>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку.
А смысл? Получится-то подмножество POSIX. А POSIX уже есть...
Здравствуйте, 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" — тут уж совсем системно-зависимые дебри.
Здравствуйте, 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" — тут уж совсем системно-зависимые дебри.
Вот. Приеду в Москву — можно об этом будет поговорить и обсудить.
Мне надо же как-то сетевое программирование студням преподавать.
На уровне Стивенса и сокетов — понятно.
А потом начинаются разные варианты...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
