= Сообщение: 2495 из 3553 ======================================== RU.GOLDED = От : Vitaliy Aksyonov 1:104/117 06 Feb 23 14:38:16 Кому : Nil A 06 Feb 23 14:38:16 Тема : Re: Как бы так голдед зарефакторить? FGHI : area://RU.GOLDED?msgid=1:104/117+63e17591 На : area://RU.GOLDED?msgid=2:5015/46+63e15527 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.GOLDED?msgid=2:5015/46+63e18296 ============================================================================== Привет, Nil!
06 Feb 23 22:07, ты писал(а) мне:
VA>> Есть желание заняться выпиливанием malloc/free и заменой на new, NA> Заодно и все memset() и memcpy() выпилить, а наче овчинка выделки не NA> стоит.
Согласен. Причем можно начать "есть мамонта" кусками. Чтобы не делать огромные изменения сразу. Их сложно будет проверять.
NA> Заодно и все рукописные динамические массивы, линкед-листы, и все те NA> дата-стракчерсы, что надо самому писать на plain C, то в C++ можно NA> немного контейнеры готовые применить, уже ~ 20% всего кода просто NA> выпилиться.
И их туда же. :)
NA> Заодно все char* на какие-нибудь std::string, но лучше на ICU, или NA> ложить в string только UTF.
Я тоже думал о замене фиксированных буферов на строки. По крайней мере там, где они уместны. Насчет UTF - это слишком много сразу. Не прожую. Может потом. Если желание не пропадет.
VA>> чтобы побочные эффекты конструкторов не терялись.
NA> В эпоху Си-с-классами, когда не было таких слов, как RVO, не говоря NA> уже об "современном" C++11 с rvalue и мув-семантикой, то вот писали NA> как просто структуры, которые можно memset и memcpy, и пофиг что там NA> вообще виртуальная функции есть, т.е. vtable, и что такие типы ниразу NA> не POD, чтобы их побитово туда-сюда.
NA> Но это уже большой рефакторинг получается.
Да нет. Убрать memset там, где должен быть конструктор - не такая уж огромная задача. Мало того, можно сделать feature branch, порезать задачи и навалиться толпой, если есть еще сумасшедшие. ;)
NA> А главное, ну окей, проверишь ты ручками на Jam/Squish/Opus базах, а NA> там в голдеде только разных баз и форматов с десяток, где ты такие NA> референсные найдёшь, или ты зачекинешь, а вы, братцы, сами там NA> проверяйте, если что поломается, то может починю, а может и забью, так NA> как мишен мой закончился на этом.
1. Можно сделать юниттесты. Для рефакторинга это самый правильный способ. 2. Без помощи, конечно, будет сложно и затянется на долго.
VA>> Плюс убрать странные конструкции в виде: VA>> recptr = new char [recsize]; VA>> throw_new(recptr);
NA> В эпоху Си-с-классами.. говорил вроде уже, не было стандарта на то, NA> что new возвращает (void*)0 или кидает исключение. Собственно, NA> исключения только потом придумали. А потом ещё и темплейты придумали. NA> Сегодня это смешно, но так было.
Я понимаю, что древние компиляторы вполне могли работать так. Тут вообще сомнительный код. Если память уже кончилась, то вызывать какой-то еще код, который попытается записать лог (и потенциально тоже будет выделять память) - затея не очень здравая.
NA> Сегодня new будет кидать исключение, и надо его ещё заставить NA> возвращать nullptr путём new(std::nothrow) NA> https://en.cppreference.com/w/cpp/memory/new/nothrow
NA> А кто более прошаренный, так и вовсе скажет, что на x86_64 у тебя new NA> всегда вернётся без ошибки, просто памяти виртуально дехера, но потом NA> ты словишь плохой автобус (SIGBUS).
Не всегда. Если тебе нужен большой кусок - то виртуальная память тут не поможет. Упадет именно аллокатор.
NA> А кто ещё ещё более прошаренный, тот скажет, ну кагбэ что вообще можно NA> сделать, когда кончается память, данихера полезного не сделаешь, NA> позакрывать все файлы, и в аборт. Кстати, ещё вопрос, тебя снесёт NA> SIGBUS, или таки oom killer ;-) А нет, мы же проверяем возврат NA> malloc() и new, и делаем что-то разумное при этом.
99%, что прибъёт OOM Killer. Только это может быть не линукс, а какая-то венда. А там OOM Killer нетути. ;)
VA>> Это ведь имеет смысл только в случае, если код собирается без VA>> поддержки исключений. NA> Ну я вот щас собиру без поддержки исключений. Есть два варианта, NA> компилятор тупо вставит std::terminate() в том месте. Второй вариант, NA> современный компилятор, увидит -fno-exceptions и throw в коде и NA> откажется компилировать.
Расскажешь о результатах. Интересно.
VA>> Кто-то знает, есть ли такие сборки или это тоже VA>> лучше выкосить? NA> Думаю gcc 4.8 примерно должен собирать, и ещё из реальных мамонтов - NA> Open Watcom 2.0.
Напишу в GOLDED попозже. Поспрашиваю, что там используют. 4.8 - вполне может использоваться в CentOS 7 именно он. Самый простой способ - не использовать C++11, а пилить в C++03 или даже 98. Но даже там есть нормальный STL.
Best regards, Vitaliy Aksyonov.
... Чем дальше в лес, тем "ну их, дрова". --- GoldED+/LNX 1.1.5-b20220504 * Origin: Aurora, Colorado (1:104/117) |