C/C++ linux разработчик. Ищу удалённую работу.

>linuxfan, а твоё определение malloc почему не конфликтует с уже имеющимся?

По-моему это связано с особенностью работы динамического линкера. Хотя когда-то давно я смотрел символы в libc.so и malloc был объявлен как weak.

Кстати, можно на классные грабли наступить из-за этой фичи: при работе с libmysqlclient определить в коде функцию my_malloc и веселая отладка обеспечена.

linuxfan, да, твой эксперимент у меня на «g++ (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3» работает (-; Печатается строка.

Но ребята тут правы насчёт возможной не связанности new / delete с функциями malloc / free в отдельных системах, это ясно. То, что на наших это связано - так сложилось. malloc и free - вообще вшивые libc-шные процедуры, ядро плевало на них.


Просто эта история про char* и delete VS delete[]... Ну то, что delete так же работает с char*, как delete[] - это тоже «так сложилось», но за этим «так сложилось» стоит какая-то сильная логика, благодаря чему оно так складывается не только у меня. Я её и хочу понять, а не на стандарт наехать.

Да всё ок. Хорошую работу всегда получает не самый умный, но самый наглый :) Автору удачи!

> Ну то, что delete так же работает с char*, как delete[] - это тоже «так сложилось», но за этим «так сложилось» стоит какая-то сильная логика, благодаря чему оно так складывается не только у меня. Я её и хочу понять, а не на стандарт наехать.

логику у микрософта сложно искать, но скорее всего дело в лени — вместо обоих delete просто вызываем free

логика в стандарте очевидна — delete может знать размер куска (ей об этом говорит компилятор) и соответственно может юзать более оптимальный аллокатор, delete[] — не знает

насколько я понимаю - для POD типов - new[]/delete[] - аналоги malloc/free

а если это не POD-тип?)))))) тогда уже вызовы конструкторов/деструкторов/виртуальных деструкторов

Это уже когда перегрузка делается, в С++ своего менеджера памяти нет, хотя ничто не ограничивает сделать свой, но большинстве случаев мало кто этим заморачивается