Тема: malloc -> new
Показать сообщение отдельно
  #6  
Старый 07.02.2023, 02:52
Nil A
Guest
 
Сообщений: n/a
По умолчанию Как бы так голдед зарефакторить?

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

Нello, Vitaliy!

Monday February 06 2023 14:38, from Vitaliy Aksyonov -> Nil A:

VA> Я тоже думал о замене фиксированных буферов на строки. По крайней мере
VA> там, где они уместны. Насчет UTF - это слишком много сразу. Не прожую.
VA> Может потом. Если желание не пропадет.

Ну окей, multibyte encoding оставить в голдеде, а не Unicode, и заменить char* на std::string.

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

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

VA> Да нет. Убрать memset там, где должен быть конструктор - не такая уж
VA> огромная задача.

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

VA> Мало того, можно сделать feature branch,

Не, чувак, у тебя код-рефактор, без новых фич прям. А фича-бренч - это про юникодный голдед.

VA> порезать задачи и навалиться толпой, если есть еще сумасшедшие. ;)

Толпы нет. Никому не интересно. Рассчитывай всегда только на себя.

VA> 1. Можно сделать юниттесты.

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

VA> Если память уже кончилась, то вызывать какой-то еще код, который
VA> попытается записать лог (и потенциально тоже будет выделять память) -
VA> затея не очень здравая.

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

VA> Не всегда. Если тебе нужен большой кусок - то виртуальная память тут
VA> не поможет. Упадет именно аллокатор.

Для этого надо много-много террабайтных файлов mmap() в память, чтобы там кончилось 32TiB пространство.

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

CFLAGS="-fno-exceptions" и вперёд, сам можешь проверить. Говорю, результат сильно зависит от твоего компилятора.

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

Да ну вас, ребята-демократы, минимум C++11ый то должен быть, а там c++17 прям нормалёк. C++20 от Ваткомов требовать не получиться ;-)

Best Regards, Nil
--- GoldED+/LNX 1.1.5
Ответить с цитированием