Comments 19
В С++ мы избегаем вызова sizeof так как размер типа вычисляется компилятором автоматически
Што, вызов sizeof?..
Смысл new в С++ не просто в выделении памяти, а вызове конструктора и начале лайфтайма объекта, в С это бессмысленно, так что получилось сделать свой код несовместимым с С++ ))
получилось сделать свой код несовместимым с С++ ))
Но ведь главной целью не было сделать код совместимым с С++. Главной целью было повторить синтаксически и максимально похоже оператор new в С, с чем я считаю справился ( за исключением скобок ) - но это уже не критично.
Не боитесь, что не сейчас, но когда-нибудь потом, за
#define new(t,...)
кто-нибудь захочет вас убить ? Возможно даже вы сами )
Ну я не считаю что макросы с переменным количеством аргументов плохи, если вы это имели ввиду. Я считаю что если такая возможность языка имеется, и её можно применить, то её нужно применить. А что плохого вы видите в их использовании? Было бы интересно послушать о минусах/подводных камнях/недостатках и неудобства их использования, да и другим будет полезно
Не в количестве переменных дело, а в дефайне new. А если хедер с этим окажется когда-нибудь включенным в плюсовый код, то редефайне. Вот радости-то будет.
Вы добавили очень сомнительной полезности сахар и положили рядом граблю
Ух это да. Но я думаю вряд-ли такое останется без внимания - компилятор сгенерирует столько ошибок, сколько было написано new, и тогда злополучная строка быстро обнаружится.
Вы добавили очень сомнительной полезности сахар и положили рядом граблю
Насчёт полезности честно не знаю - вкусовщина. Кому-то тип легче написать, а кому-то sizeof подтянуть. Всё ради эксперимента
Кстати такая же неприятность может случиться вот с таким макросом:
#define for(...)Проблем доставит ещё больше чем дефайн new.
#ifndef __cplusplus
// #define new, etc
#endif
Но с остальными Вашими доводами вполне согласен
Придумать оператор new, который похож на new из С++, но немного другой - можно. Но зачем???
Я ожидал увидеть самодельный аллокатор, а не вот это.
немного неудобно организована работа с памятью
Да она вообще неправильно организована от слова совсем.
Например вы не можете контролировать выделение/освобождение/выравнивание/учет памяти, не можете поменять метод выделения и ограничения на количество, даже просто определить сколько выделено и кем вы не можете. Не говоря уже о том что бы автоматически освобождать ресурсы которые понавыделял остановленный поток или подпрограмма и вообще сколько и она дочерних потоков запустила при жизни. Не говоря о передачи способа выделения памяти в подпрограмму.
И в свете лютой многопоточности и многоступенчатого механизма кэшей каждый поток может хотеть иметь собственный пул память с разной иерархией скорости доступа. И в таких ситуациях вы вынуждены будете использовать кастомные аллокаторы и все эти эргономичные ухищрения c #define new вам не понадобятся, тем более что такой метод способен сломать больше чем кажется.
ps: В C++ есть RAII и предлагается что все ресурсы программа которая их выделила, сама их и освободит. Но можно в C ничего подобного нет и не надо соблюдать эту условность. т.е. можно сделать «завещание» которое можно использовать для освобождения ресурсов при внезапной смерти потока/функции/fsm. Более того такой способ позволит ограничивать время исполнения кода, т.к. это такой же ресурс как и память например.
Кажется, malloc(n * sizeof(int)) выглядит лучше, чем malloc(n, int). Прозрачнее и идиоматичнее, фактически на русском языке написано, что происходит, это почти что реализация именованных параметров в языке без их поддержки :). При этом sizeof - это не вызов функции, и умножение тоже не будет в рантайме производиться (если n - константа).
Слава богу в этот раз бред этого студента заминусовали.
Умный malloc для С