Действительно ли это - хорошая практика к свободной памяти через указатель на константу

Просто идея.

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

Щелкните файл mse7.exe , установленный вместе с Office, обычно по адресу \Program Files\Microsoft Office\OFFICE11 .

Откроется отладчик, файл, а затем отладчик будет запущен в режиме графического интерфейса пользователя.

Я никогда не понимал аргументов против удаления (или освобождения) конст-указателя. Точнее, я несколько вижу рациональные, но мне кажется, что они одинаково хорошо применимы к конст- члена в объекте или конст-переменной в блоке, И я никогда не видел, чтобы кто-то утверждал, что они не должны быть уничтожены и их память освобождена, когда содержащий объект удален или исполнение оставляет их содержащий блок.

Два вопроса управления логической мутабельностью объектов (то есть const или not) и управления их продолжительностью жизни (то есть использовать объектную переменную, смарт-указатель - который и один - или необработанный указатель) мне кажутся не связанными.

Другими словами, если

{
    Foo const x;
    ...
}

является допустимым и хорошим стилем. Почему

{
    Foo const* xptr = new Foo;
    ...
    delete xptr;
}

не был бы хорошим стилем (использование адекватного умного указателя вместо сырого, но это другой вопрос).

Постоянство и время жизни - две разные вещи. Я не вижу проблем с освобождением константного объекта, если владелец этого объекта решает, что у объекта нет причин для жизни (точно так же, как объект const , который является локальным, будет «освобожден», когда он выйдет из области видимости) .

Что касается free () , не использующего указатель const , я думаю, что можно утверждать, что это могло быть недосмотром комитета по стандартам или что это потому, что он принимает тот же вид, если указатель, возвращаемый malloc () .

Рекомендуется использовать правильную стратегию для завершения жизненного цикла объекта. Для динамических объектов это означает удаление того, что вы создали, освободите то, что вы выбрали, и так далее. Независимо от того, является ли этот объект константой или нет, не влияет на то, должно ли закончиться его время жизни.

Быть постоянными или изменчивыми - это свойства, которые существуют в течение жизни объекта и заканчиваются выражением удаления или вызовом free. Независимо от вашего собственного взгляда на этот вопрос или того, как все работает на других языках, именно так работает объектная модель C ++. Простой пример, показывающий, как язык переводит выражения удаления в вызовы оператора удаления:

#include <new>
void* operator new(std::size_t size);
void operator delete(void* p);

int main() {
  delete new int(); // int* to void*, since this is also an allowed
  // implicit conversion, it may not be clear what is happening

  // however, these are clearly not implicit conversions:
  delete new int const();          // int const         * to void*
  delete new int volatile();       // int       volatile* to void*
  delete new int const volatile(); // int const volatile* to void*
}

Другой пример, но, возможно, менее ясный, - почему вы не можете перегрузить ctors на const:

struct S {
  S() const; // not allowed
};

Объект является константным только после created (он же время жизни начинается; происходит, когда ctor возвращается в обычном режиме) и до его уничтожения (иначе, его время жизни заканчивается; происходит при входе в dtor). До или после этого времени жизни у вас может быть указатель типа T const * (например), но он не указывает на объект и разыменование его - это UB.

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

(Я считаю, что этот вопрос является субъективным и аргументированным , и я бы проголосовал за его закрытие таким образом, за исключением того, что я, по-видимому, помог вызвать обсуждение; поэтому отвечу как CW.)