I
T это же некий тип, чего там компилятору не мочь?
Size: a a a
2021 July 12
A
Пример неинтересный, но я немного поэкспериментировал и вы наверно правы, наверно оптимизация этого бессмысленна или может быть накладнее
SS
Ну а зачем сложнее, если все идеально просто
а
delete[] должен вызвать деструктор типа T 10 раз, по одному разу для каждого элемента массива по указателю arr. вопрос в том откуда delete[] узнаёт что в массиве 10 элементов
I
еще раз аллокатор за этим следит
I
реализация кучи
SS
I
не аллокатор оси, а цппшный
SS
I
I
в стандарте это compiler specific
I
аллокатор оси ток знает размер всего блока
П
Там рядом с массивом же инфа кладется, чот такое
I
а скока в нем элементов знает аллокатор конкретной реализации цпп
I
в гцц так точно, за других не скажу
I
в конец кучи дописывается метаинфа
A
Ну например если вызов delete[] рядом можно например попросить меньше памяти, и положить размер в регистр.
С компайлтаймовыми размерами опять таки если компилятор видит и new и delete можно оптимизировать.
Ну тут вероятно не особо нужно + просто компилятору нужно тогда как то установить связь между вызовом new и delete.
С компайлтаймовыми размерами опять таки если компилятор видит и new и delete можно оптимизировать.
Ну тут вероятно не особо нужно + просто компилятору нужно тогда как то установить связь между вызовом new и delete.
A
Нет, аллокатор знает только сколько байт он отдал пользователю аллокатора
I
аллокатор дописывает метаинфу в конец кучи
I
потом он эту инфу юзает для удаления