Test

Cheslav Osanadze написал(а) к Vladimir Fyodorov в Jan 23 22:08:48 по местному времени:

Привет Vladimir!

20 Янв 23 20:51, Vladimir Fyodorov -> Vitaliy Aksyonov:


VF> то бага нет. Кто-нибудь может объяснить, в чём тут порылась собака и
VF> как её избежать?

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


Cheslav.


... В порочащих связях был, но не замечен
--- ...

Nil A написал(а) к Vitaliy Aksyonov в Jan 23 22:36:16 по местному времени:

* Originally in hobbit.test
* Crossposted in su.c_cpp
Нello, Vitaliy!

Friday January 20 2023 11:57, from Vitaliy Aksyonov -> Nil A:

Префаза. в локальной тестовой эхе hobbit.test последние несколько дней, довольно в активном ритме, случается много интересных CPP обсуждений, поэтому кросс-пострю в профильную эху su.c_cpp.

NA>> Звучит как реклама C++.
VA> Но это ведь правда. Плюсы довольно низкоуровневы, чтобы писать
VA> эффективный код, но при этом не насолько, как голый си, чтобы писать
VA> удобно, безопасно и понятно человеку.

До появления в C++11 lvalues, там были сплошные копирования тяжёлых структур данных. Были даже отдельные реализации, похожие на STL, где есть move всего содержимого контейнера.

И до появления явного правила RVO в C++11 (aka copy elision), был вообще караул с возвратом значений, приходилось через параметры гонять указатель или ссылку.

Кстати, на этом примере, покажу как стандарты C++ сосут. RVO правило сразу не заработало, надо было ещё потом NRVO прописать, и потом в C++17 ещё пришлось "guaranteed copy elision through simplified value categories" прописывать.

А если у тебя там какой-то side-effects из-за вызовов copy/move конструктотров? Ну так-то, чтобы не было side-effect, надо сразу на Нaskell писать, пока тебе не потребовалось из файла почитать, где сайд-эффекты прут как из рога изобилия, и тут на сцену выходят монады. Кстати, в жопу хаскель, монадный синтаксис уже плотно перекачевал в C++. И, вот ещё пример, как C++ стандарт сосёт. В C++17 добавили std::optional, который устанешь каждый раз проверять, и в других языках ты пишешь .andthen, или .orelse, или transform. Они добавили в C++23 монадный синтаксис, вместе с std::expected наконец (но мы то все уже давно сидим на https://github.com/TartanLlama/expected).

Кстати, вот пример, как в 90х писали на C++, в до C++11, на примере голдеда. Так то голдед, можно сказать, что ООП, по настоящему, где есть интерфейсный класс, с виртуальными функциями почитать разные форматы баз сообщений. Например, в Нusky это сделано на голом Си, через макрос, который через указатель попадает на структуру с адресами функций, такой ручной переход по v-table. Так вот, в голдеде везде оптимизации в виде memset()/memcpy() на sizeof класса, как будто он весь такой POD, хоть там и виртуальные функции есть. Кстати, там в голдеде новодел есть, в лице std::string и std::vector, ну честно же, так удонее, чем руками тут же писать разные linked list. Но вот классы с std::string и std::vector прям удалять и копировать через memset()/memcpy() как-то совсем плохо, однажды запустив под valgrind увидишь там потерянные std::vector.

Я пример с голдедом привёл зачем. Чтобы показать, что на C++ нельзя было пейсать эффективный код. И только сейчас, с помощью всех этих шаблонов, constexpr выражений, можно получить эффективный бинарный код на выходе, опять же, при условии, что программист знает что получится, когда он именно вот так вот напишет, проверив на каком-нибудь https://godbolt.org . Кстати, SFINAE должно умереть, и всё это должно быть уже if constexpr с разными concepts требованиями к типам.

VA> Смотрел видосик на ютубчике, как один товарищ про const
VA> рассказывал. Так там как раз был пример, когда он то ли
VA> добавлял, то ли наоборот убирал const и несколько ассемблерных
VA> инструкций превращалось в тонны кода.

"Один-товарищ", его зовут Jason Turner, его канал https://www.youtube.com/@cppweekly

Проблема с ним лично в том, что он далёк от продакшен кода. Он раскрутился на консалтинге, кодревь, и прочих разводках, что щас кого-то наймём и он "фсё починит".

Вообще, с ними со всеми проблема общая в том, что если ты не умеешь программировать, то ты идёшь в менеджеры. Если не умеешь руководить, то ты идёшь учить других как программировать. Если не умеешь учить, то ты пишешь книжки.

VA> У нас еще веселее. Мы в своем компоненте совмещаем асинхронный подход
VA> (самописные очереди на boost asio) и многопоточность. А в другом
VA> компоненте к этим двум еще добавили stackful корутины из буста. Иногда
VA> бывают очень занятные баги.

С++20 корутины должны сильно помочь, но проблема, что так и не дали библиотеку в std:: неймспейсе, чтобы корутины использовать "из-коробки", приходится cppcoro, им подобными, или самописными пользоваться.

VA> С корутинами был интересный прикол. Мы портировали этот код с винды на
VA> линукс и он начал странно крешиться иногда. Выяснилось, что при
VA> выделении памяти для стека она выделялась без выравнивания и вместо
VA> stack overflow код вылазил в чужую память и крешился. Было непросто
VA> найти причину.

Не надо stackful и stackless корутины в одном коде миксить.

Кстати, придёт к тебе на работу джун, которых в школе учили критические секции мьютексами защищать, а тут у тебя корутины, и как ты его код отревьювишь?

NA>> Кстати, в C++ комитете полно русский людей, что радует.
VA> Наслышан. Вроде STL наши написали первоначально.

Ты не знаешь кто такой Степанов Сан Саныч? Вики тебе в помощь.

VA> Большой плюс котлина, что он использует ту же JRE. А она почти везде
VA> есть или может работать.

На таком же принципе появляются новые языки программирования, как грибы, и все такие C++ убицы. Вот тебе тройка из 2022 года.
* Val https://www.val-lang.dev
* Carbon https://github.com/carbon-language/carbon-lang сам Гугл учавствует, считай уже 3ий язык после Go и Dart.
* cppfront https://github.com/hsutter/cppfront
Все они поразитируют на том, что совместимы с C++, только более модно/молодёжные.

VA>>> Мы пока используем fmt либу. Одинаково работает. Вот на C++20
VA>>> перейдем - заменим на std::
NA>> Когда поддержка будет везде. Когда они ещё доприлят std::chrono с
NA>> таймзонами или хотябы с std::chrono::local_t, чтобы не тащить
NA>> https://github.com/НowardНinnant/date.git и чтобы std::format ещё
NA>> это мог напечатать.
VA> Таймзоны - это боль. У нас 4 раза в год вылазят баги с ними. :)
VA> Спросишь, почему 4? Потому что перевод часов на зимнее и летнее время
VA> в США и в других странах происходит в разные дни.

Ты мне рассказываешь, как два раза в год у нас есть неделя, когда митинги с США и Европейцами расходятся на час?

NA>> Буст - это тестовая площадка для будущего C++ стандарта.
VA> Именно. Из него очень многое перехало почти без изменений. Те же умные
VA> указатели или ranges.

std::filesystem::path тоже из Буста. Но, забавно, Google C++ Style Guide явно запрещает его использовать из-за "security vulnerability". Чувак как-то умудрились
Time-of-check to time-of-use проблему притащить в самом спеке, как тот самый mktemp() страдает.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Nil A написал(а) к Vitaliy Aksyonov в Jan 23 23:50:26 по местному времени:

Нello, Vitaliy!

Friday January 20 2023 11:57, from Vitaliy Aksyonov -> Nil A:

NA>> Короче да, получай ноду в зиване, будешь как настоящий старпёр,

VA> В процессе. Если на непарольное мыло не ответит - буду пробовать
VA> достать его другими средствами.

Непарольное мыло никто не читает в зиване.
Ещё, будь готов, что типичный зивановец не ставит пароли на pkt, надо в конфиге разрешить, иначе не растоссится.

VA> Я бы и модем поднял, но у меня нет телефонной линии.

VoIP с g.721 кодеком тебе даст 9600 и иногда больше беспалевно.
Я тут, кстати, заморочился, нашёл несколько полностью софтовых модемов, чтобы на x86 крутить и в SIP пихать, но из-за пропраетарности этих v32bis всех, оно немного не опенсорц, а на 2400 дудеть мне не охота. Всегда можно чорный курьер + ata186 (или аналог) запустить, и получишь типа 19200 даже.

VA> Это было бы вообще аутентично.

В Зивановке есть модемные федо, не вопрос. Опять же, тоссят они раз в сутки потом. Мега аутентично.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Nil A написал(а) к Vitaliy Aksyonov в Jan 23 23:56:24 по местному времени:

Нello, Vitaliy!

Friday January 20 2023 12:23, from Vitaliy Aksyonov -> Nil A:

NA>> Пошукал по своим линкам, обе pvt.luna.local и pvt.luna.tech
NA>> (роботы срут), есть на 2:5020/715 * 2:5020/830 * 2:5023/23
NA>> 2:5030/722

VA> Ну если придет - отпишусь туда. Интересно. Если не пролезет - будем
VA> восстанавливать.

Скорее всего там всё оборвано, раз я твоё письмо уже не увидил на 5020/715.
Я могу тут как long link выступить, и твою локалку в звезду повезать со всеми этими линками.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Vladimir Fyodorov написал(а) к Nil A в Jan 23 23:13:40 по местному времени:

Разнообразно приветствую!

NA> Кагбэ в гадалке не ходи, что на 2:5023/23 оно будет из первых рук,
NA> как говориться

https://images.app.goo.gl/2qjnba6WT2k32PuKA

--
Всяческих благ. Искренне Ваш, Vladimir Fyodorov, эсквайр.
... Пропала несущая? Заплатите налоги!
--- Нotdoged/2.13.5/Android

Vladimir Fyodorov написал(а) к Cheslav Osanadze в Jan 23 00:03:23 по местному времени:

Разнообразно приветствую!

VF>> то бага нет. Кто-нибудь может объяснить, в чём тут порылась
VF>> собака и как её избежать?
CO> Я так глубоко не стал погружаться, что бы описывать твит для
CO> разных эх, просто отрубаю твит руками, в нужных.:)

Ну, во-первых, ты вряд ли много эх модерируешь, чтобы это заметить. Во-вторых, возможно, ты вообще не используешь твиты.

--
Всяческих благ. Искренне Ваш, Vladimir Fyodorov, эсквайр.
... Пропала несущая? Заплатите налоги!
--- Нotdoged/2.13.5/Android

Vitaliy Aksyonov написал(а) к Nil A в Jan 23 14:40:14 по местному времени:


Нello Nil!

20 Jan 23 22:36, you wrote to me:

NA> Префаза. в локальной тестовой эхе hobbit.test последние несколько
NA> дней, довольно в активном ритме, случается много интересных CPP
NA> обсуждений, поэтому кросс-пострю в профильную эху su.c_cpp.

Конечно. Не вопрос.

NA>>> Звучит как реклама C++.
VA>> Но это ведь правда. Плюсы довольно низкоуровневы, чтобы писать
VA>> эффективный код, но при этом не насолько, как голый си, чтобы
VA>> писать удобно, безопасно и понятно человеку.

NA> До появления в C++11 lvalues, там были сплошные копирования тяжёлых
NA> структур данных. Были даже отдельные реализации, похожие на STL, где
NA> есть move всего содержимого контейнера.

Ты перепутал с rvalues. lvalues были с самого рождения.

NA> И до появления явного правила RVO в C++11 (aka copy elision), был
NA> вообще караул с возвратом значений, приходилось через параметры гонять
NA> указатель или ссылку.

Или указатели. Да и сейчас много где используется, особенно, если объект надо отдать в несколько потоков и кто его удалит - заранее неизвестно.

NA> Кстати, на этом примере, покажу как стандарты C++ сосут. RVO правило
NA> сразу не заработало, надо было ещё потом NRVO прописать, и потом в
NA> C++17 ещё пришлось "guaranteed copy elision through simplified value
NA> categories" прописывать.

Всего сразу предусмотреть невозможно. Особенно в таком монстре, как плюсы. Пожалуй не найдется ни одного человека в мире, включая авторов стандарта, который может сказать, что знает плюсы на 100%. Можно неплохо разбираться в какой-то одной-двух областях, но полностью не знать. Он тупо оргомный.

NA> А если у тебя там какой-то side-effects из-за вызовов copy/move
NA> конструктотров? Ну так-то, чтобы не было side-effect, надо сразу на
NA> Нaskell писать, пока тебе не потребовалось из файла почитать, где
NA> сайд-эффекты прут как из рога изобилия, и тут на сцену выходят монады.
NA> Кстати, в жопу хаскель, монадный синтаксис уже плотно перекачевал в
NA> C++. И, вот ещё пример, как C++ стандарт сосёт. В C++17 добавили
NA> std::optional, который устанешь каждый раз проверять, и в других
NA> языках ты пишешь .andthen, или .orelse, или transform. Они добавили
NA> в C++23 монадный синтаксис, вместе с std::expected наконец (но мы то
NA> все уже давно сидим на https://github.com/TartanLlama/expected).

С std::optional связана другая история. Мы сейчас на gcc7.3. И в нем есть косяк в инициализации std::optional. Приходится вставлять костыли, чтобы warning не выкидывало.

NA> Кстати, вот пример, как в 90х писали на C++, в до C++11, на примере
NA> голдеда. Так то голдед, можно сказать, что ООП, по настоящему, где
NA> есть интерфейсный класс, с виртуальными функциями почитать разные
NA> форматы баз сообщений. Например, в Нusky это сделано на голом Си,
NA> через макрос, который через указатель попадает на структуру с адресами
NA> функций, такой ручной переход по v-table. Так вот, в голдеде везде
NA> оптимизации в виде memset()/memcpy() на sizeof класса, как будто он
NA> весь такой POD, хоть там и виртуальные функции есть. Кстати, там в
NA> голдеде новодел есть, в лице std::string и std::vector, ну честно же,
NA> так удонее, чем руками тут же писать разные linked list. Но вот классы
NA> с std::string и std::vector прям удалять и копировать через
NA> memset()/memcpy() как-то совсем плохо, однажды запустив под valgrind
NA> увидишь там потерянные std::vector.

memset/memcpy в плюсах вообще быть не должно. Как и new/delete. Я посмотрел немного код деда - это жесткое легаси. Там работать и работать. Даже компиляция с -Wall выдает прилично предупреждений.

NA> Я пример с голдедом привёл зачем. Чтобы показать, что на C++ нельзя
NA> было пейсать эффективный код. И только сейчас, с помощью всех этих
NA> шаблонов, constexpr выражений, можно получить эффективный бинарный код
NA> на выходе, опять же, при условии, что программист знает что получится,
NA> когда он именно вот так вот напишет, проверив на каком-нибудь
NA> https://godbolt.org . Кстати, SFINAE должно умереть, и всё это должно
NA> быть уже if constexpr с разными concepts требованиями к типам.

Когда пейсался голдед - плюсы были "C с классами". И большинство пейсателей писали так, как привыкли на голых сях. А там особо не развернешься.

SFINAE - тоже прикольный пример. Например в boost::bind был реализован просто через набор шаблонов до 20 параметров. Еслибольше - хрен. Но это приводило к тому, что когда возникает ошибка компиляции - вываливает тонны нечитаемого текста. Я когда только начинал boost использовать - очень страдал от этого. Каждая такая ошибка приводила к мучительному поиску ошибки, которая в большинстве случаев была вообще в другом файле. Например, попытка скопировать некопируемый класс.

VA>> Смотрел видосик на ютубчике, как один товарищ про const
VA>> рассказывал. Так там как раз был пример, когда он то ли
VA>> добавлял, то ли наоборот убирал const и несколько ассемблерных
VA>> инструкций превращалось в тонны кода.

NA> "Один-товарищ", его зовут Jason Turner, его канал
NA> https://www.youtube.com/@cppweekly

Он самый.

NA> Проблема с ним лично в том, что он далёк от продакшен кода. Он
NA> раскрутился на консалтинге, кодревь, и прочих разводках, что щас
NA> кого-то наймём и он "фсё починит".

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

NA> Вообще, с ними со всеми проблема общая в том, что если ты не умеешь
NA> программировать, то ты идёшь в менеджеры. Если не умеешь руководить,
NA> то ты идёшь учить других как программировать. Если не умеешь учить, то
NA> ты пишешь книжки.

Именно так это работает. Как книжки от "трейдеров" как зарабатывать деньги на бирже. Если бы это реально работало, то книги такие никто бы не печатал, тупо рубили бы бабло.

VA>> У нас еще веселее. Мы в своем компоненте совмещаем асинхронный
VA>> подход (самописные очереди на boost asio) и многопоточность. А в
VA>> другом компоненте к этим двум еще добавили stackful корутины из
VA>> буста. Иногда бывают очень занятные баги.

NA> С++20 корутины должны сильно помочь, но проблема, что так и не дали
NA> библиотеку в std:: неймспейсе, чтобы корутины использовать
NA> "из-коробки", приходится cppcoro, им подобными, или самописными
NA> пользоваться.

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

VA>> С корутинами был интересный прикол. Мы портировали этот код с
VA>> винды на линукс и он начал странно крешиться иногда. Выяснилось,
VA>> что при выделении памяти для стека она выделялась без
VA>> выравнивания и вместо stack overflow код вылазил в чужую память и
VA>> крешился. Было непросто найти причину.

NA> Не надо stackful и stackless корутины в одном коде миксить.

Конечно. Иначе начинается каша, которую хрен разберешь. Мы не мешали одно с другим. Асинхронный код у нас не на корутинах.

NA> Кстати, придёт к тебе на работу джун, которых в школе учили
NA> критические секции мьютексами защищать, а тут у тебя корутины, и как
NA> ты его код отревьювишь?

Очень просто. Он будет читать книжки, прежде чем писать код. :)

NA>>> Кстати, в C++ комитете полно русский людей, что радует.
VA>> Наслышан. Вроде STL наши написали первоначально.

NA> Ты не знаешь кто такой Степанов Сан Саныч? Вики тебе в помощь.

Точно. Вылетело имя из головы. Он самый.

VA>> Большой плюс котлина, что он использует ту же JRE. А она почти
VA>> везде есть или может работать.

NA> На таком же принципе появляются новые языки программирования, как
NA> грибы, и все такие C++ убицы. Вот тебе тройка из 2022 года. * Val
NA> https://www.val-lang.dev * Carbon
NA> https://github.com/carbon-language/carbon-lang сам Гугл учавствует,
NA> считай уже 3ий язык после Go и Dart. * cppfront
NA> https://github.com/hsutter/cppfront Все они поразитируют на том, что
NA> совместимы с C++, только более модно/молодёжные.

Это разумный подход. Ведь написать нормальный компилятор, который еще и оптимизирует толково - это работа на десяток лет или даже больше. А эти все "языги" - просто препроцессоры в плюсовый код или максимум AST. Потом какой-то LLVM в работу.

VA>> Таймзоны - это боль. У нас 4 раза в год вылазят баги с ними. :)
VA>> Спросишь, почему 4? Потому что перевод часов на зимнее и летнее
VA>> время в США и в других странах происходит в разные дни.
NA> Ты мне рассказываешь, как два раза в год у нас есть неделя, когда
NA> митинги с США и Европейцами расходятся на час?

У меня та же картина. У нас есть офисы в Европе. Так что мы друг друга понимаем.

NA>>> Буст - это тестовая площадка для будущего C++ стандарта.
VA>> Именно. Из него очень многое перехало почти без изменений. Те же
VA>> умные указатели или ranges.

NA> std::filesystem::path тоже из Буста. Но, забавно, Google C++ Style
NA> Guide явно запрещает его использовать из-за "security vulnerability".
NA> Чувак как-то умудрились Time-of-check to time-of-use проблему
NA> притащить в самом спеке, как тот самый mktemp() страдает.

Из буста очень много чего перетащили в стандарт. Такая себе песочница. А почему бы и нет. Работает.

Vitaliy


... 10.0 times 0.10 is hardly ever 1.00.
--- GoldED+/LNX 1.1.5-b20220504

Vitaliy Aksyonov написал(а) к Nil A в Jan 23 14:56:18 по местному времени:


Нello Nil!

20 Jan 23 23:50, you wrote to me:

NA>>> Короче да, получай ноду в зиване, будешь как настоящий старпёр,
VA>> В процессе. Если на непарольное мыло не ответит - буду пробовать
VA>> достать его другими средствами.
NA> Непарольное мыло никто не читает в зиване.
NA> Ещё, будь готов, что типичный зивановец не ставит пароли на pkt, надо
NA> в конфиге разрешить, иначе не растоссится.

Подожду еще несколько дней. Если не выйдет на связь - напишу по роутингу. Надеюсь, оно дойдет. :) К сожалению, я не знаю других его контактов. Квест, так квест. Хочется ж сделать все по процессу. Как в полиси прописано.

VA>> Я бы и модем поднял, но у меня нет телефонной линии.
NA> VoIP с g.721 кодеком тебе даст 9600 и иногда больше беспалевно.
NA> Я тут, кстати, заморочился, нашёл несколько полностью софтовых
NA> модемов, чтобы на x86 крутить и в SIP пихать, но из-за пропраетарности
NA> этих v32bis всех, оно немного не опенсорц, а на 2400 дудеть мне не
NA> охота. Всегда можно чорный курьер + ata186 (или аналог) запустить, и
NA> получишь типа 19200 даже.

Ну это как резиновая женщина. А как же пожужжать хендшейком? Правда, все равно оно потом у провайдера заворачивается в какой-то электронный поток на первой же АТС.

VA>> Это было бы вообще аутентично.
NA> В Зивановке есть модемные федо, не вопрос. Опять же, тоссят они раз в
NA> сутки потом. Мега аутентично.

Есть. Но проблема в том, что у меня нет линии. И платить хрен знает сколько за нее интереса нет. Цены на связь тут дикие. Я привык до переезда совсем к другим условиям. :)

Vitaliy


... 10.0 times 0.10 is hardly ever 1.00.
--- GoldED+/LNX 1.1.5-b20220504

Vitaliy Aksyonov написал(а) к Nil A в Jan 23 15:00:26 по местному времени:


Нello Nil!

20 Jan 23 23:56, you wrote to me:

NA>>> Пошукал по своим линкам, обе pvt.luna.local и pvt.luna.tech
NA>>> (роботы срут), есть на 2:5020/715 * 2:5020/830 * 2:5023/23
NA>>> 2:5030/722
VA>> Ну если придет - отпишусь туда. Интересно. Если не пролезет -
VA>> будем восстанавливать.
NA> Скорее всего там всё оборвано, раз я твоё письмо уже не увидил на
NA> 5020/715. Я могу тут как long link выступить, и твою локалку в звезду
NA> повезать со всеми этими линками.

100% порвано. В нее никто с 2017 года не писал.

Vitaliy


... 10.0 times 0.10 is hardly ever 1.00.
--- GoldED+/LNX 1.1.5-b20220504

Nil A написал(а) к Vitaliy Aksyonov в Jan 23 01:41:10 по местному времени:

Нello, Vitaliy!

Friday January 20 2023 14:40, from Vitaliy Aksyonov -> Nil A:

VA> Ты перепутал с rvalues. lvalues были с самого рождения.

Оговорился.

VA> Или указатели. Да и сейчас много где используется, особенно, если
VA> объект надо отдать в несколько потоков и кто его удалит - заранее
VA> неизвестно.

Звучит как std::shared_ptr, если не известно кто и в каком потоке прибьёт. Или как в qt, есть некий parent, который держит всё остальное.

VA> Пожалуй не найдется ни одного человека в мире, включая авторов
VA> стандарта, который может сказать, что знает плюсы на 100%.

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

Кстати, FTSC ещё хуже, они говорят, низя и всё. Почему? Потому что дядя Randy Bush копирайт держит на центральный FTS-0001. А нахуй вы тогда нужны? А мы чтобы обновлять FTA-1003 регулярно.

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

Там вопрос даже в другом, там нельзя вот так вот взять и "переписать с нуля", должно быть легаси-совместимо. Поэтому там полно костылей. Поэтому появляются всякие D языки ;-) убийцы C++.

Про всё предусмотреть, ну вот std::string, например, в c++23 добавили contains() наконец таки, в c++20 добавили startswith()/endswith(). В питонах это с версии2 ещё, с той не юникодной.

Кстати, вот из-коробки я хочу на C++ почитать файлы, и их полочить надо, либо замапить в память, но такова нету. И даже нельзя достать int fd. Из fopen() я могу достать fileno(), а из C++ fstream никак без хака. А если я захочу почитать как корутина, например, уже в лиункс фейсбуки отдали io_uring, и даже твой любимый boost:asio так умеет. Ну окей, давайте сделаем IO thread pool (как какой-нибудь Libuv), и будет все файловые операции туда кидать, но ведь thread pool так и не завезли, только сраный std:async, который не оправдывает своего названия. Кстати, в федо, которое умерло, сегодня самый гуру линуксов - это Гремлин. Он в рулинуксе в прошлом году даже стал спорить со мной, что на epoll якобы можно повесить файловые операции асинхронно, так же как и сокеты.

Про юникод, я хочу открыть файл, и указать кодировку, и хочу получать std::string каких-нибудь кодепоинтов, или рунов, или чего-то такова, что я обычно в python, golang,.. получаю. QString так умеет, внутри utf16, но мне пофиг на реализацию. В этом плане qt именно core, без GUI части, он мог бы закрыть многие потребности обычного с++ пейсателя, то, что в libc++ сделали неудобно, или не сделали совсем.

VA> memset/memcpy в плюсах вообще быть не должно. Как и new/delete.

Ну я на кодревью new/delete не пропущу, но сам я пишу вон placement new в готовом буфере, некая оптимизация при принятии сетевых пакетов, например.
А вот memcpy() тоже пришлось применить, ибо std::equal оказался не готов хавать std::bytes также как и unsigned char, я даже на стековерфлоу тут возмутился https://stackoverflow.com/questions/75121121

memcpy() будет на buildin заменён компилятный, а он сука знает про ему суют, выравненно оно или нет (а то бы я сам просто reinterpretcast<uint32t>(адрес) делал бы), и он разные 256битные регистры можно использовать при копировании, если march задан не низкий.

VA> Когда пейсался голдед - плюсы были "C с классами". И большинство
VA> пейсателей писали так, как привыкли на голых сях. А там особо не
VA> развернешься.

Труъ.
Кстати, про стандарто-пейсателей. Я щитаю, самый большой их косяк был - это std::auto_ptr ;-) понятно что сегодня его уже депрекейтнули, но осадочек остался.

VA> SFINAE - тоже прикольный пример. Например в boost::bind был реализован
VA> просто через набор шаблонов до 20 параметров. Еслибольше - хрен. Но
VA> это приводило к тому, что когда возникает ошибка компиляции -
VA> вываливает тонны нечитаемого текста. Я когда только начинал boost
VA> использовать - очень страдал от этого. Каждая такая ошибка приводила к
VA> мучительному поиску ошибки, которая в большинстве случаев была вообще
VA> в другом файле. Например, попытка скопировать некопируемый класс.

К сожалению, сегодняшнюю libc++ не переписали на c++20 concepts, и если там напортачить с std::optional, в котором возвращается std::uniqueptr, да ещё как-нибудь через .and_then(), то там 10 экранов шаблонной магии вылезает, а могло быть всего одна строчка, что вот требование такое то не совпало. Хотя, они уже там потрудились staticassert() по максимуму понапихать, чтобы в таком виде свалилось, а не в SFINAE.

VA> Именно так это работает. Как книжки от "трейдеров" как зарабатывать
VA> деньги на бирже. Если бы это реально работало, то книги такие никто бы
VA> не печатал, тупо рубили бы бабло.

Если бы экстрасенсы могли узнавать что-то через специфичный API, который они так декларируют, то они бы просто все были бы миллионерами от выигрыша в лотерею, или на фондовом рынке. :-)

VA> Корутины имеет смысл использовать там, где много IO. Так же, как и
VA> асинхронное программирование. Иначе особого прироста они не дают.

Ну сокеты все. И это всё реализовано. Но часто надо ещё и фалы почитать, а вот это почитать асинхронно уже сложнее.

Ещё коруинами обзывают то, что называется генераторами на самом деле. Хотя вроде современный std::ranges::views::iota как-то без co_yield внутри вроде.

Best Regards, Nil
--- GoldED+/LNX 1.1.5