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

Привет, Nil!

07 Feb 23 01:21, ты писал(а) мне:

VA>> Я тоже думал о замене фиксированных буферов на строки. По крайней
VA>> мере там, где они уместны. Насчет UTF - это слишком много сразу.
VA>> Не прожую. Может потом. Если желание не пропадет.
NA> Ну окей, multibyte encoding оставить в голдеде, а не Unicode, и
NA> заменить char* на std::string.

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

NA> И уже потом решать проблему юникодизации голдеда. На самом деле, там
NA> надо сделать не больше, не меньше а как в референсном rtin проекте -
NA> хранить utf8, типа вычитали кодировку из сообщения, и сразу в utf8
NA> стринги.

Это в идеале. Внутри везде оперировать в юникоде. Но не все сразу. :)

NA> Я вообще думал, похоронить все там способы отображения, через DOS int
NA> 13h или какой там, через WinAPI консоль, через OS/2 чего-то, а просто,
NA> как в rtin (моя скрытая любовь, ну ты понял уже), там типа ncurses и
NA> ещё вариант ANSI вроде, но тоже лишне.

Опять же. Это намного больший рефакторинг, на который я готов прямо сейчас.

VA>> Да нет. Убрать memset там, где должен быть конструктор - не такая
VA>> уж огромная задача.
NA> Они там переиспользуют память под объекты таким образом. Там бы ещё
NA> все raw pointers на std::unique_ptr заменить заодно. Кстати! Даже все
NA> линтеры всего мира не ловят за руку так, как включение юник-поинтера в
NA> класс, тогда у тебя копирование уже не возможно, которое, оказывается
NA> там под шумок происходило, а только явный муф.

Я видел. Там еще "сериализация"/"десереиализация" сделана через тупо вычитку куска файла в память, а потом обзывание этого объектом. Только если выравнивание поменяется - привет. Приехали.

VA>> Мало того, можно сделать feature branch,
NA> Не, чувак, у тебя код-рефактор, без новых фич прям. А фича-бренч - это
NA> про юникодный голдед.

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

VA>> порезать задачи и навалиться толпой, если есть еще сумасшедшие.
VA>> ;)
NA> Толпы нет. Никому не интересно. Рассчитывай всегда только на себя.

Ну я так и думаю. Но мало ли. ;)

VA>> 1. Можно сделать юниттесты.
NA> Тыж не программист на зряплате, забыл? Яб позвонил щас Одинну, типа
NA> чувак, как ты ваще тестировал свою хрень, ни одного юниттеста, давай
NA> ты щас свою попу из тёплой Копенгаговской пастельки вынешь, и
NA> вспомнишь, где ты видел все те фидоные базёнки, и быстренько
NA> юниктестики на гуглотеста накидаешь. Но Одинн щас "leading figure in
NA> Internet Marketing", вот здесь написано
NA> https://www.youtube.com/@OdinnAdalsteinsson/about разочаровал конечно.

Юниттесты отбирают кучу времени... Но для рефакторинга отличная тема.

VA>> Если память уже кончилась, то вызывать какой-то еще код, который
VA>> попытается записать лог (и потенциально тоже будет выделять
VA>> память) - затея не очень здравая.
NA> Ну я вижу следующий юзкейс, например, для тоссера на мини-роутере -
NA> вижу размер сообщения в lorapvt.bigfiles 2метра, делаю malloc(2metra),
NA> возвращается NULL (на 32bit, на 64bit OK всегда), и типа океюшки, не
NA> буду всю мессагу в память засасывать, а буду по 4096 байтов копировать
NA> туда-сюда.

Вариант. Но там в большинстве случаев просто terminate вызывается.

VA>> Не всегда. Если тебе нужен большой кусок - то виртуальная память
VA>> тут не поможет. Упадет именно аллокатор.
NA> Для этого надо много-много террабайтных файлов mmap() в память, чтобы
NA> там кончилось 32TiB пространство.

Совсем необязательно. Попробуй выделить один кусок памяти, который больше, чем у тебя есть физически на боксе. Возможно плюс своп. Будешь удивлен.

NA>>> Ну я вот щас собиру без поддержки исключений. Есть два варианта,
NA>>> компилятор тупо вставит std::terminate() в том месте. Второй
NA>>> вариант, современный компилятор, увидит -fno-exceptions и throw
NA>>> в коде и откажется компилировать.
VA>> Расскажешь о результатах. Интересно.
NA> CFLAGS="-fno-exceptions" и вперёд, сам можешь проверить. Говорю,
NA> результат сильно зависит от твоего компилятора.

Я так не играю. Ты написал, что сам соберешь. ;)

VA>> Напишу в GOLDED попозже. Поспрашиваю, что там используют. 4.8 -
VA>> вполне может использоваться в CentOS 7 именно он. Самый простой
VA>> способ - не использовать C++11, а пилить в C++03 или даже 98. Но
VA>> даже там есть нормальный STL.
NA> Да ну вас, ребята-демократы, минимум C++11ый то должен быть, а там
NA> c++17 прям нормалёк. C++20 от Ваткомов требовать не получиться ;-)

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

Best regards,
Vitaliy Aksyonov.

... Рыба-пила и рыба-закyсывала.
--- GoldED+/LNX 1.1.5-b20220504