malloc -> new

Vitaliy Aksyonov написал(а) к All в Feb 23 19:44:16 по местному времени:

Привет, All!

Есть желание заняться выпиливанием malloc/free и заменой на new, чтобы побочные эффекты конструкторов не терялись.
Плюс убрать странные конструкции в виде:

recptr = new char [recsize];
throw_new(recptr);

record = (MaxUsers*)recptr;
memset(record, 0, recsize);

Еще часто в коде встречается подобная конструкция:

field* fld = new field(this, idnum, wrow, wcol, fieldwidth, dest, destsize, cvt, mode);
throw_new(fld);

Это ведь имеет смысл только в случае, если код собирается без поддержки исключений. Кто-то знает, есть ли такие сборки или это тоже лучше выкосить?

Best regards,
Vitaliy Aksyonov.

... Стратег ремонта: а не yдарить ли нам внезапно кyвалдой с тыла?
--- GoldED+/LNX 1.1.5-b20220504

Michael Dukelsky написал(а) к Vitaliy Aksyonov в Feb 23 19:04:58 по местному времени:

Нello Vitaliy,

05 February 2023, Vitaliy Aksyonov wrote to All:

VA> Есть желание заняться выпиливанием malloc/free и заменой на new, чтобы
VA> побочные эффекты конструкторов не терялись. Плюс убрать странные
VA> конструкции в виде:

VA> recptr = new char [recsize];
VA> throw_new(recptr);

VA> record = (MaxUsers*)recptr;
VA> memset(record, 0, recsize);

VA> Еще часто в коде встречается подобная конструкция:

VA> field* fld = new field(this, idnum, wrow, wcol, field_width, dest,
VA> destsize, cvt, mode); thrownew(fld);

VA> Это ведь имеет смысл только в случае, если код собирается без
VA> поддержки исключений. Кто-то знает, есть ли такие сборки или это тоже
VA> лучше выкосить?

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

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707

Vitaliy Aksyonov написал(а) к Michael Dukelsky в Feb 23 09:10:42 по местному времени:

Привет, Michael!

06 Feb 23 19:04, ты писал(а) мне:

VA>> Есть желание заняться выпиливанием malloc/free и заменой на new,
VA>> чтобы побочные эффекты конструкторов не терялись. Плюс убрать
VA>> странные конструкции в виде:

VA>> recptr = new char [recsize];
VA>> throw_new(recptr);

VA>> record = (MaxUsers*)recptr;
VA>> memset(record, 0, recsize);

VA>> Еще часто в коде встречается подобная конструкция:

VA>> field* fld = new field(this, idnum, wrow, wcol, field_width,
VA>> dest, destsize, cvt, mode); thrownew(fld);

VA>> Это ведь имеет смысл только в случае, если код собирается без
VA>> поддержки исключений. Кто-то знает, есть ли такие сборки или это
VA>> тоже лучше выкосить?

MD> Этот вопрос лучше задавать в англоязычный эхе GOLDED. Там есть люди,
MD> пользующиеся старыми компиляторами.

Спасибо за совет. Подпишусь туда попозже и поспрашиваю.

Best regards,
Vitaliy Aksyonov.

... Упёртость умирает последней!
--- GoldED+/LNX 1.1.5-b20220504

Nil A написал(а) к Vitaliy Aksyonov в Feb 23 22:07:32 по местному времени:

* Originally in ru.golded
* Crossposted in su.c_cpp
Нello, Vitaliy!

Sunday February 05 2023 19:44, from Vitaliy Aksyonov -> All:

VA> Есть желание заняться выпиливанием malloc/free и заменой на new,

Заодно и все memset() и memcpy() выпилить, а наче овчинка выделки не стоит.

Заодно и все рукописные динамические массивы, линкед-листы, и все те дата-стракчерсы, что надо самому писать на plain C, то в C++ можно немного контейнеры готовые применить, уже ~ 20% всего кода просто выпилиться.

Заодно все char* на какие-нибудь std::string, но лучше на ICU, или ложить в string только UTF.

VA> чтобы побочные эффекты конструкторов не терялись.

В эпоху Си-с-классами, когда не было таких слов, как RVO, не говоря уже об "современном" C++11 с rvalue и мув-семантикой, то вот писали как просто структуры, которые можно memset и memcpy, и пофиг что там вообще виртуальная функции есть, т.е. vtable, и что такие типы ниразу не POD, чтобы их побитово туда-сюда.

Но это уже большой рефакторинг получается.

А главное, ну окей, проверишь ты ручками на Jam/Squish/Opus базах, а там в голдеде только разных баз и форматов с десяток, где ты такие референсные найдёшь, или ты зачекинешь, а вы, братцы, сами там проверяйте, если что поломается, то может починю, а может и забью, так как мишен мой закончился на этом.

VA> Плюс убрать странные конструкции в виде:
VA> recptr = new char [recsize];
VA> throw_new(recptr);

В эпоху Си-с-классами.. говорил вроде уже, не было стандарта на то, что new возвращает (void*)0 или кидает исключение. Собственно, исключения только потом придумали. А потом ещё и темплейты придумали. Сегодня это смешно, но так было.

Сегодня new будет кидать исключение, и надо его ещё заставить возвращать nullptr путём new(std::nothrow) https://en.cppreference.com/w/cpp/memory/new/nothrow

А кто более прошаренный, так и вовсе скажет, что на x86_64 у тебя new всегда вернётся без ошибки, просто памяти виртуально дехера, но потом ты словишь плохой автобус (SIGBUS).

А кто ещё ещё более прошаренный, тот скажет, ну кагбэ что вообще можно сделать, когда кончается память, данихера полезного не сделаешь, позакрывать все файлы, и в аборт. Кстати, ещё вопрос, тебя снесёт SIGBUS, или таки oom killer ;-) А нет, мы же проверяем возврат malloc() и new, и делаем что-то разумное при этом.

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

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

VA> Кто-то знает, есть ли такие сборки или это тоже
VA> лучше выкосить?

Думаю gcc 4.8 примерно должен собирать, и ещё из реальных мамонтов - Open Watcom 2.0.

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

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

Привет, 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

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

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

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

Нello, Vitaliy!

Monday February 06 2023 15:48, from Vitaliy Aksyonov -> Nil A:

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

Готов/неготов, там мой спелчекер спотыкается.
Кагбэ это твой коммитмент, что ты там хочешь в голдеде починить.
Прям если ты щас скажешь, что сделаешь голдед векторным и гипертекстовым, а потом сольёшься, то тебя тухлыми помидорами закидают потом.
Хотя, голдед реально стал гипертекстовым, на фичабренче GoldED-NSF https://fido.g0x.ru/golded/ патчик тут https://fido.g0x.ru/gpl/fido/golded/...i</b>v003.diff
Вот, влей его в мейнстрим хотябы.

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

Одно дело alignment, а ещё есть endianness. Нельзя вот так просто взять, и закастить поинтер на кусок памяти на структурку ;-)

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

Ты прав, огромный пулреквест у тебя встрянет на совсем, ибо никто не понимает, что ты хотел там сделать.
А если ты тут malloc на new заменил, а тут правильный delete[] вместе delete написал, то тебе заапрувят высшие силы (про которых Мистер Одинн даже не слышал ниразу).

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

Ну окей, низнаю какой именно маллок ты изаешь, может он знает максимум как memtotal+swap, но и это ничиго не значит.

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

Дяд Гремлин, мега авторитет-всея-R50 сказал, что можно дропнуть всё, кроме вин+линукс+мак, или он это про хаски сказал, но мне пофиг, ты просто не говорил ещё с этими, которые на ВаткомСи сидят, у них там чудеса вообще.

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

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

Привет, Nil!

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

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

там было "не готов". Пропустил. :)

NA> Кагбэ это твой коммитмент, что ты там хочешь в голдеде починить.
NA> Прям если ты щас скажешь, что сделаешь голдед векторным и
NA> гипертекстовым, а потом сольёшься, то тебя тухлыми помидорами закидают
NA> потом. Хотя, голдед реально стал гипертекстовым, на фичабренче
NA> GoldED-NSF https://fido.g0x.ru/golded/ патчик тут
NA> https://fido.g0x.ru/gpl/fido/golded/...i</b>v003.diff Вот,
NA> влей его в мейнстрим хотябы.

А что мешало аффтару залить этот дифф? ;) Мне-то не проблема оформить пулл-реквест. Если афтор неротив и остальная публика.

VA>> Я видел. Там еще "сериализация"/"десереиализация" сделана через
VA>> тупо вычитку куска файла в память, а потом обзывание этого
VA>> объектом. Только если выравнивание поменяется - привет. Приехали.
NA> Одно дело alignment, а ещё есть endianness. Нельзя вот так просто
NA> взять, и закастить поинтер на кусок памяти на структурку ;-)

Ну вы тут со своими маками не лезьте к нормальным людям.

VA>> Я к тому, чтобы можно было на ревью отправлять куски поменьше и
VA>> не заливать при этом в мастер.
NA> Ты прав, огромный пулреквест у тебя встрянет на совсем, ибо никто не
NA> понимает, что ты хотел там сделать. А если ты тут malloc на new
NA> заменил, а тут правильный delete[] вместе delete написал, то тебе
NA> заапрувят высшие силы (про которых Мистер Одинн даже не слышал
NA> ниразу).

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

NA>>> Для этого надо много-много террабайтных файлов mmap() в память,
NA>>> чтобы там кончилось 32TiB пространство.
VA>> Совсем необязательно. Попробуй выделить один кусок памяти,
VA>> который больше, чем у тебя есть физически на боксе. Возможно плюс
VA>> своп. Будешь удивлен.
NA> Ну окей, низнаю какой именно маллок ты изаешь, может он знает максимум
NA> как memtotal+swap, но и это ничиго не значит.

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

VA>> Не думаю, что выпилить сразу кучу старых компиляторов - здравая
VA>> идея. Пусть этим пользуются два калеки, но все же.
NA> Дяд Гремлин, мега авторитет-всея-R50 сказал, что можно дропнуть всё,
NA> кроме вин+линукс+мак, или он это про хаски сказал, но мне пофиг, ты
NA> просто не говорил ещё с этими, которые на ВаткомСи сидят, у них там
NA> чудеса вообще.

Надо попробовать этот компилятор скачать для разнообразия. МОжет там уже давно все сломано. :)

Best regards,
Vitaliy Aksyonov.

... 1 лошадиная сила - сила, которую развивает лошадь весом 1кг и ростом 1м.
--- GoldED+/LNX 1.1.5-b20220504

Alexey Vissarionov написал(а) к Nil A в Feb 23 06:09:00 по местному времени:

Доброго времени суток, Nil!
07 Feb 2023 04:22:50, ты -> Vitaliy Aksyonov:

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

В любом случае закидают, независимо от результата :-)

NA> Хотя, голдед реально стал гипертекстовым, на фичабренче GoldED-NSF
NA> https://fido.g0x.ru/golded/ патчик тут
NA> https://fido.g0x.ru/gpl/fido/golded/...i</b>v003.diff Вот,
NA> влей его в мейнстрим хотябы.

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

VA>> Я видел. Там еще "сериализация"/"десереиализация" сделана через
VA>> тупо вычитку куска файла в память, а потом обзывание этого объектом.
VA>> Только если выравнивание поменяется - привет. Приехали.
NA> Одно дело alignment, а ещё есть endianness. Нельзя вот так просто
NA> взять, и закастить поинтер на кусок памяти на структурку ;-)

Дык в памяти можно вытворять что угодно... А вот из файлов читать напрямую в структуры лучше не надо.

NA>>> Для этого надо много-много террабайтных файлов mmap() в память,
NA>>> чтобы там кончилось 32TiB пространство.
VA>> Совсем необязательно. Попробуй выделить один кусок памяти, который
VA>> больше, чем у тебя есть физически на боксе. Возможно плюс своп.
VA>> Будешь удивлен.
NA> Ну окей, низнаю какой именно маллок ты изаешь, может он знает
NA> максимум как memtotal+swap, но и это ничиго не значит.

Выделиться-то он, может быть, и выделится, но при попытке работать с этим огромным блоком в какой-то момент прилетит SIGSEGV.

VA>> Не думаю, что выпилить сразу кучу старых компиляторов - здравая идея.
VA>> Пусть этим пользуются два калеки, но все же.
NA> Дяд Гремлин, мега авторитет-всея-R50 сказал, что можно дропнуть всё,
NA> кроме вин+линукс+мак,

Эти три платформы нельзя ломать. Особенно первые две.
Ибо говна не оберешься.

NA> или он это про хаски сказал,

Я это про весь FTN-софт говорил.

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

Вот как раз поддержку DOS можно выкидывать совершенно спокойно.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Облачных технологий не существует - существуют только чужие компутеры
--- /bin/vi