Безопасно ли удалять нулевой указатель?

Question

Безопасно ли удалять нулевой указатель?

263

Можно ли удалить указатель NULL?

И это хороший стиль кодирования?

qiuxiafei 16 нояб. 2010, в 02:22

Источник

14

Хорошей практикой является написание программ на C ++ без единого вызова delete . Вместо этого используйте RAII . То есть используйте std::vector<T> v(100); вместо T* p = new T[100]; используйте умные указатели, такие как unique_ptr<T> и shared_ptr<T> которые заботятся об удалении, вместо необработанных указателей и т. д.
fredoverflow 19 нояб. 2010, в 17:26
8

благодаря make_shared (c ++ 11) и make_unique (c ++ 14) ваша программа должна содержать ноль new и delete
sp2danny 21 окт. 2014, в 11:54
2

В некоторых случаях все еще могут быть редкие случаи, требующие new / delete, например, atomic <T *>: atomic <unique_ptr <T >> не разрешен, а atomic <shared_ptr <T >> имеет издержки, которые в некоторых случаях могут быть неприемлемы
atb 02 апр. 2015, в 14:05
2

Чтобы объявить класс с управлением ресурсами с помощью RAII, вам нужно вызвать new и delete right?, Или вы говорите, что есть некоторый шаблонный класс, чтобы скрыть это даже это.
VinGarcia 21 окт. 2016, в 01:44
1

@VinGarcia Суть в том, что большинству пользовательских / клиентских (то есть небиблиотечных) кодов никогда не придется писать new или delete . Классы, предназначенные для управления ресурсами, в которых стандартные компоненты не могут выполнять свою работу, могут, конечно, делать то, что им нужно, но дело в том, что они делают ужасные вещи с памятью, которой они управляют, а не с кодом конечного пользователя. Таким образом, сделать собственную библиотеку / вспомогательный класс , чтобы сделать new / delete , и использовать этот класс вместо них.
underscore_d 28 окт. 2018, в 13:20
0

Возможные дубликаты. Есть ли причина проверять нулевой указатель перед удалением?
underscore_d 28 окт. 2018, в 13:36

Показать ещё 4 комментария

Теги:

c++

pointers

memory-management

delete-operator

null-pointer

7 ответов

72

Из проекта стандарта С++ 0x.

$5.3.5/2 - "[...] В любом случае альтернатива, значение операнда удаления может быть нулевым указателем значение. [..."

Конечно, никто не будет "удалять" указателя со значением NULL, но это безопасно. В идеале не должно быть кода, который бы удалял указатель NULL. Но иногда полезно, когда удаление указателей (например, в контейнере) происходит в цикле. Так как удаление значения указателя NULL безопасно, можно действительно написать логику удаления без явных проверок для удаления операнда NULL.

В качестве отступления, стандарт C $7.20.3.2 также говорит, что "свободный" по указателю NULL не выполняет никаких действий.

Свободная функция вызывает пробел на который указывает ptr, который должен быть освобожден, то есть доступный для дальнейшего распределение. Если ptr - нулевой указатель, никаких действий не происходит.

Chubsdad 16 нояб. 2010, в 03:33

1

Мне бы очень хотелось, чтобы этот ответ содержался в цитатах, если он намеренно не привел к неэффективности неоптимизированного кода. Как говорится в принятом ответе, удаление нулевого указателя не допускается. Поэтому проверка, является ли указатель нулевым, перед его удалением является абсолютно посторонним.
codetaku 24 март 2016, в 16:11

44

Да, это безопасно.

Нет вреда при удалении нулевого указателя; он часто уменьшает количество тестов в хвосте функции, если нераспределенные указатели инициализируются до нуля, а затем просто удаляются.

Поскольку предыдущее предложение вызвало путаницу, пример - который не является безопасным исключением - того, что описывается:

void somefunc(void)
{
    SomeType *pst = 0;
    AnotherType *pat = 0;

    …
    pst = new SomeType;
    …
    if (…)
    {
        pat = new AnotherType[10];
        …
    }
    if (…)
    {
        …code using pat sometimes…
    }

    delete[] pat;
    delete pst;
}

Есть все виды нит, которые можно выбрать с помощью кода примера, но концепция (я надеюсь) понятна. Переменные указателя инициализируются на ноль, так что операциям delete в конце функции не нужно проверять, не являются ли они ненужными в исходном коде; код библиотеки выполняет проверку в любом случае.

Jonathan Leffler 16 нояб. 2010, в 03:46

0

Я должен был прочитать это несколько раз, чтобы понять это. Вы должны иметь ввиду инициализацию их нулями в начале метода или во время, а не в хвосте, конечно? В противном случае вы просто удалите как обнуление, так и удаление.
user207421 08 сен. 2014, в 22:58
1

@EJP: не совсем неправдоподобный план функции может быть следующим: void func(void) { X *x1 = 0; Y *y1 = 0; … x1 = new[10] X; … y1 = new[10] Y; … delete[] y1; delete[] x1; } Я не показывал никакой блочной структуры или переходов, но операции delete[] в конце безопасны из-за инициализации в начале. Если что-то подпрыгнуло до конца после того, как был выделен x1 и до того, как был выделен y1 и не было инициализации y1 , тогда было бы неопределенное поведение - и хотя код мог проверять на нулевое значение ( x1 и y1 ) перед удалением, нет необходимости делать это.
Jonathan Leffler 08 сен. 2014, в 23:26

19

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

Если вы ищете хорошие методы кодирования, подумайте об использовании интеллектуальных указателей, а затем вам не нужно delete вообще.

Brian R. Bondy 16 нояб. 2010, в 03:20

17

время, когда люди хотят удалить указатель NULL, это когда они не уверены, содержит ли он NULL ... если бы они знали, что это NULL, то они бы не рассматривали удаление и, следовательно, спрашивали ;-).
Tony Delroy 16 нояб. 2010, в 04:44
0

@ Тони: Я только хотел сказать, что это не будет иметь никакого эффекта, и наличие такого кода, который удаляет указатель, который иногда содержит NULL, не обязательно плох.
Brian R. Bondy 16 нояб. 2010, в 13:02
3

IMO избыточные проверки, безусловно, плохи для производительности, удобочитаемости и ремонтопригодности.
paulm 25 фев. 2014, в 00:56
0

@paulm OP, конечно, не говорит о таких плохих вещах, скорее о Seg Fault / UB.
Winter 26 июнь 2017, в 20:08

Показать ещё 2 комментария

3

Чтобы дополнить ruslik ответ, в С++ 14 вы можете использовать эту конструкцию:

delete std::exchange(heapObject, nullptr);

ashrasmun 08 нояб. 2017, в 15:24

2

Это безопасно, если вы не перегрузили оператора удаления. если вы перегрузили оператор delete и не обрабатывали нулевое состояние, это небезопасно.

user4016479 16 нояб. 2014, в 12:10

0

Не могли бы вы добавить какое-либо объяснение вашего ответа?
Marcin Nabiałek 16 нояб. 2014, в 11:19
0

Вы имеете в виду, что это безопасно, если вы не перегружены удалить?
sth 16 нояб. 2014, в 14:54

0

Я испытал, что небезопасно (VS2010) удалять [] NULL (т.е. синтаксис массива). Я не уверен, соответствует ли это стандарту С++.

Безопасно удалять NULL (скалярный синтаксис).

pheest 30 авг. 2013, в 17:52

6

Это незаконно, и я не верю этому.
Konrad Rudolph 30 авг. 2013, в 16:56
5

Вы должны быть в состоянии удалить любой нулевой указатель. Так что, если он ломается для вас, то, вероятно, у вас есть ошибка в коде, который показывает это.
Mysticial 30 авг. 2013, в 17:00
3

§5.3.2 Во второй альтернативе (удалить массив) значением операнда удаления может быть нулевое значение указателя или значение указателя, полученное из предыдущего массива new-expression.
sp2danny 16 авг. 2014, в 05:12
0

@KonradRudolph Что незаконно?
Opux 14 март 2017, в 20:33
1

@Opux Поведение VS2010 заявлено в ответе. Как объяснено в других комментариях, безопасно delete[] NULL .
Konrad Rudolph 14 март 2017, в 21:52
0

@KonradRudolph Возможно, но VS известен его причудами, таким образом это по крайней мере правдоподобно.
Opux 15 март 2017, в 14:22
1

@Opux Вот почему я написал «я не верю в это», а не «это неправильно». Но я все еще не знаю, и это было бы довольно вопиющим, глупым нарушением стандарта. На самом деле VC ++ довольно хорошо соблюдает ограничения стандарта, и места, где он их нарушает, имеют исторический смысл.
Konrad Rudolph 15 март 2017, в 17:03

Показать ещё 5 комментариев

Ещё вопросы

Хорошей практикой является написание программ на C ++ без единого вызова delete . Вместо этого используйте RAII . То есть используйте std::vector<T> v(100); вместо T* p = new T[100]; используйте умные указатели, такие как unique_ptr<T> и shared_ptr<T> которые заботятся об удалении, вместо необработанных указателей и т. д.
благодаря make_shared (c ++ 11) и make_unique (c ++ 14) ваша программа должна содержать ноль new и delete
В некоторых случаях все еще могут быть редкие случаи, требующие new / delete, например, atomic <T *>: atomic <unique_ptr <T >> не разрешен, а atomic <shared_ptr <T >> имеет издержки, которые в некоторых случаях могут быть неприемлемы
Чтобы объявить класс с управлением ресурсами с помощью RAII, вам нужно вызвать new и delete right?, Или вы говорите, что есть некоторый шаблонный класс, чтобы скрыть это даже это.
@VinGarcia Суть в том, что большинству пользовательских / клиентских (то есть небиблиотечных) кодов никогда не придется писать new или delete . Классы, предназначенные для управления ресурсами, в которых стандартные компоненты не могут выполнять свою работу, могут, конечно, делать то, что им нужно, но дело в том, что они делают ужасные вещи с памятью, которой они управляют, а не с кодом конечного пользователя. Таким образом, сделать собственную библиотеку / вспомогательный класс , чтобы сделать new / delete , и использовать этот класс вместо них.
Возможные дубликаты. Есть ли причина проверять нулевой указатель перед удалением?
Мне бы очень хотелось, чтобы этот ответ содержался в цитатах, если он намеренно не привел к неэффективности неоптимизированного кода. Как говорится в принятом ответе, удаление нулевого указателя не допускается. Поэтому проверка, является ли указатель нулевым, перед его удалением является абсолютно посторонним.
Я должен был прочитать это несколько раз, чтобы понять это. Вы должны иметь ввиду инициализацию их нулями в начале метода или во время, а не в хвосте, конечно? В противном случае вы просто удалите как обнуление, так и удаление.
@EJP: не совсем неправдоподобный план функции может быть следующим: void func(void) { X *x1 = 0; Y *y1 = 0; … x1 = new[10] X; … y1 = new[10] Y; … delete[] y1; delete[] x1; } Я не показывал никакой блочной структуры или переходов, но операции delete[] в конце безопасны из-за инициализации в начале. Если что-то подпрыгнуло до конца после того, как был выделен x1 и до того, как был выделен y1 и не было инициализации y1 , тогда было бы неопределенное поведение - и хотя код мог проверять на нулевое значение ( x1 и y1 ) перед удалением, нет необходимости делать это.
время, когда люди хотят удалить указатель NULL, это когда они не уверены, содержит ли он NULL ... если бы они знали, что это NULL, то они бы не рассматривали удаление и, следовательно, спрашивали ;-).
@ Тони: Я только хотел сказать, что это не будет иметь никакого эффекта, и наличие такого кода, который удаляет указатель, который иногда содержит NULL, не обязательно плох.
IMO избыточные проверки, безусловно, плохи для производительности, удобочитаемости и ремонтопригодности.
@paulm OP, конечно, не говорит о таких плохих вещах, скорее о Seg Fault / UB.
Не могли бы вы добавить какое-либо объяснение вашего ответа?
Вы имеете в виду, что это безопасно, если вы не перегружены удалить?
Вы должны быть в состоянии удалить любой нулевой указатель. Так что, если он ломается для вас, то, вероятно, у вас есть ошибка в коде, который показывает это.
§5.3.2 Во второй альтернативе (удалить массив) значением операнда удаления может быть нулевое значение указателя или значение указателя, полученное из предыдущего массива new-expression.
@Opux Поведение VS2010 заявлено в ответе. Как объяснено в других комментариях, безопасно delete[] NULL .
@KonradRudolph Возможно, но VS известен его причудами, таким образом это по крайней мере правдоподобно.
@Opux Вот почему я написал «я не верю в это», а не «это неправильно». Но я все еще не знаю, и это было бы довольно вопиющим, глупым нарушением стандарта. На самом деле VC ++ довольно хорошо соблюдает ограничения стандарта, и места, где он их нарушает, имеют исторический смысл.

ruslik · Accepted Answer · 2010-11-16T03-33-00.000Z

210

Лучший ответ

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

Мне также понравилось бы, если бы delete по умолчанию устанавливал параметр NULL, как в

#define my_delete(x) {delete x; x = NULL;}

(Я знаю о значениях R и L, но было бы неплохо?)

ruslik 16 нояб. 2010, в 03:33

68

Обратите внимание, что все еще могут быть несколько других указателей, указывающих на один и тот же объект, даже если вы устанавливаете один в NULL при удалении.
sth 16 нояб. 2010, в 02:47
2

@ Конечно, но все же лучше, чем ничего. В большинстве случаев есть только один указатель.
ruslik 16 нояб. 2010, в 02:48
12

В большинстве случаев в моем коде указатель выходит из области видимости после удаления. Гораздо безопаснее, чем просто установить его в NULL.
jalf 16 нояб. 2010, в 04:03
0

@jalf, а как насчет членов класса-указателя?
ruslik 16 нояб. 2010, в 04:05
3

что насчет них? Как правило, это умные указатели или члены моего собственного специального класса RAII, который, как я уже сказал, выходит из области видимости при удалении указателя - или они указывают на объект, срок жизни которого превышает срок действия объект, содержащий указатель.
jalf 16 нояб. 2010, в 05:42
3

@ruslik: члены класса выходят из области видимости, когда содержащий объект выходит из области видимости. Следовательно, в dtor нет никакого смысла устанавливать их в ноль. Теперь в операторе присваивания может потребоваться удалить указатель на подобъект, но только если у вас уже есть new подобъект ! delete старый объект в первую очередь небезопасно - вы можете вообще не получить подобъекта. Следовательно, вы не установите указатель на NULL; вы бы установили его на новый объект.
MSalters 16 нояб. 2010, в 09:20
6

@ruslik: необработанные члены-указатели - очень плохая идея в современном C ++.
fredoverflow 19 нояб. 2010, в 17:27
125

Очень хорошая практика - не устанавливать указатель на NULL после удаления. Установка указателя на NULL после удаления маскирует ошибки выделения памяти, что очень плохо. Правильная программа не удаляет указатель дважды, а программа, которая удаляет указатель дважды, должна аварийно завершить работу.
Damon 30 авг. 2013, в 18:48
6

@Damon Программа, которая удаляет указатель, установленный на объект, а затем удаляет указатель, установленный в NULL, является правильным. Это то, что говорит стандарт.
Alice 17 март 2014, в 14:02
14

@ Алиса: Неважно, что говорит стандарт в этом отношении. Стандарт определил, что удаление нулевого указателя допустимо по какой-то абсурдной причине 30 лет назад, так что это законно (скорее всего, наследие Си). Но удаление одного и того же указателя дважды (даже после изменения его битовой комбинации) все еще является серьезной программной ошибкой. Не по формулировке стандарта, а по логике программы и владению. Как и удаление нулевого указателя, поскольку нулевой указатель не соответствует ни одному объекту , поэтому ничего нельзя удалить. Программа должна точно знать, является ли объект действительным и кому он принадлежит, и когда он может быть удален.
Damon 17 март 2014, в 15:01
4

@Alice: В другом стандартном варианте это неудачное правило стандарта позволяет программам, которые ведут себя ошибочно (надеюсь, я правильно написал), выполнять как-будто правильно. На самом деле, действительность и владение объектами вообще не ясны (можно сказать, что это догадки). Это работает только случайно, потому что проблема игнорируется. Лучшим подходом будет ранний сбой (или выбросить, если хотите), что заставит разработчика убедиться в правильности логики программы. Установка указателя на (T*)1 вместо nullptr сделает это, он будет сильно зависать, если вы попытаетесь удалить его снова.
Damon 17 март 2014, в 15:04
7

@ Damon Правильность программы продиктована правильностью поведения программ по отношению к спецификации. Часть этой спецификации связана с пользователем (выполняет ли код то, что я хочу), а часть связана со стандартами (соответствует ли она правилам языка). В обоих случаях программа, которая освобождает NULL, является правильной; он следует правилам языка и не вызывает ошибок. Не работает "случайно"; это обсуждалось и включалось в стандарт не просто как унаследованное, а потому, что это полезно и убирает проверки на NULL в тех областях, где они бессмысленны. Он работает так, как был разработан C ++.
Alice 18 март 2014, в 04:32
10

@Damon Вы навязываете свои собственные убеждения в области правильности кода: указатели представляют тип опции со слабой ссылкой, а NULL указывает на отсутствие значения. Удаление типа опции должно быть, по теории типов, определено и для необязательной части; в противном случае это не обязательно. Таким образом, вы должны быть в состоянии безопасно удалить NULL; в противном случае вы нарушаете типовой контракт и, следовательно, не можете доказать правильность. Право собственности не имеет значения: указатели слабы по причине, используйте shared_ptr, если это ваш вариант использования. Программа не должна знать точно, кто является владельцем; это нужно только не подорвать его ограничения.
Alice 18 март 2014, в 04:50
1

@ Алиса: C ++ был стандартизирован через 8 лет после изобретения одним человеком. Комитет по стандартизации должен был заверить прежде всего в одном: убедиться, что подавляющее большинство кода, использующего эту ошибку, не сломалось. Поскольку не было никакого реального "решения". Ваша интерпретация стандарта, конечно, правильна, но педантична. Программа, которая не знает, когда объект действителен , неверна . Владение ресурсом - это не азартная игра, не взгляд в хрустальный шар или что-то, что вы оставляете на волю случая. Это то, что однозначно и четко определено в хорошо написанной программе.
Damon 18 март 2014, в 12:27
8

@ Damon Во-первых, это не так; Стандарт внес несколько изменений, которые привели к поломке подавляющего большинства кода. Смотрите историю STL для деталей. Во-вторых, правильность программы не существует в вакууме; Вы должны доказать правильность программы в соответствии со спецификацией. Четкая определенность имеет спецификацию: выполняет ли программа одно и то же каждый раз, когда запускается с одинаковыми значениями? Наконец, двусмысленность означает, что два одинаково достоверных результата происходят из одинаковых значений. Правильность подразумевает четкое определение, что подразумевает двусмысленность. Ни один из них никоим образом не связан со знанием того, является ли объект действительным.
Alice 18 март 2014, в 14:24
9

@ Damon Удаление NULL не является неоднозначным; он делает то же самое каждый раз. Это хорошо определено; спецификация существует и говорит, что она делает, и каждый раз делает одно и то же. И это правильно; И IO программы соответствуют спецификации, и она соответствует спецификации теорий типов для необязательных типов. Кроме того, валидность объекта не влияет ни на одно из них; слабые указатели могут указывать на действительные или недействительные объекты, но они не являются двусмысленными, плохо определены или неверны. А без дополнительной работы невозможно доказать, действительны они или нет; это непостижимо. Любая программа на C ++ с необработанными указателями неверна?
Alice 18 март 2014, в 14:29
1

@ Алиса: Ты не понимаешь. Если у вас есть указатель, этот указатель либо неинициализирован / недействителен, либо указывает на объект (не владеет им), либо он владеет объектом. Неважно, что это то, что должно быть точно и однозначно известно во все времена. Существует ровно один экземпляр - указатель-владелец, которому разрешено (и необходимо) удалять объект в строго определенное время. Если это не так, ваша логика программы неверна. Удаление допустимого значения NULL и установка недопустимых указателей на это значение скрывает эту проблему. Это делает программы, которые не получают права собственности "хорошо себя ведут".
Damon 18 март 2014, в 14:42
7

@ Дэймон То, что ты сказал, просто ложно. Предположим, что у меня есть необработанный указатель на некоторый объект, как и некоторая структура (это часто происходит в QT, WT и т. Д.). Каркас удаляет этот объект, возможно, в ответ на код, который я не могу контролировать. Теперь у меня есть указатель на недопустимый объект, но я не знаю, что он недопустим (и на самом деле не могу знать, так как большая часть кода, на который я ссылаюсь, находится вне моего контроля). Кроме того, не существует понятия указателя-владельца; все указатели могут удалить объект, на который они указывают, и ни один из них не требуется; совершенно правильно разрешить куче очищать тривиальные объекты при закрытии программы.
Alice 18 март 2014, в 14:54
9

@ Дэймон Недостаток в том, что у вас драконовское представление о праве собственности, которого не требуют ни стандарт, ни теория типов, ни логика вообще. Каждое из ваших «требований» может быть отменено без потери правильности; несколько указателей могут удалять, указатели не нужны, указатели времени удаления не должны быть четко определены, а слабые указатели не должны знать, что объект, на который они указывают, недействителен. Но ничего из этого не имеет отношения к удалению NULL, являющемуся легальным, или установке указателей на NULL, чтобы скрыть двойные свободные; на самом деле это повышает правильность, потому что это означает, что программы не показывают неправильное или неопределенное поведение.
Alice 18 март 2014, в 15:00
5

@Alice: Я желаю вам удачи в будущем, так как несколько направлений работы становятся (или фактически уже) нормой, а не исключением. Такие идеи, как «любой указатель может удалить» или «право собственности и время удаления не должны быть четко определены», помогут вам в написании надежных программ и заслужат большую любовь среди ваших коллег.
Damon 18 март 2014, в 15:22
10

@ Damon Я поддерживаю несколько структур без блокировок и пытаюсь опубликовать статью о новой версии без блокировок. Одной из основных характеристик свободной от блокировок структуры является то, что поток может нуждаться в помощи другому потоку, а не в продвижении самостоятельно. Это часто требует нескольких указателей, каждый из которых способен удалять. Это, на самом деле, доказуемо верно для некоторых алгоритмов на оборудовании с только CAS, а не DCAS (большинство коммерческих аппаратных средств). Кроме того, время, когда удаление может происходить в таких сценариях, часто не является четко определенным, в том смысле, что они не будут происходить в одно и то же время при каждом выполнении.
Alice 18 март 2014, в 15:33
25

@Damon Однако, несмотря на эти нарушения ваших правил драконовского владения, структуры без блокировок доказуемо более надежны, чем структуры на основе блокировок. И да, мои коллеги действительно любят меня за расширенный профиль выполнения, который обеспечивают эти структуры, и за строгую безопасность потоков, которую они поддерживают, что позволяет легче рассуждать о коде (отлично подходит для обслуживания). Однако ни одно из этих действий, ни ваше предполагаемое личное нападение не имеют отношения к определению правильности, обоснованности или права собственности. То, что вы предлагаете, - это хорошее эмпирическое правило, но оно не является универсальным законом и не закреплено в стандарте.
Alice 18 март 2014, в 15:36
2

«Я знаю о значениях R и L» - но, видимо, вы не знаете о ссылках. <template T> void my_delete(T*& p) { delete p; p = NULL; }
Jim Balter 10 нояб. 2014, в 20:10
2

@ Алиса "Слабым указателям не нужно знать, что объект, на который они указывают, является недействительным" - они узнают, могут ли они быть удалены; в этом случае им нужен счетчик ссылок, чтобы избежать многократного освобождения. «Но все это не имеет отношения к удалению NULL, являющемуся допустимым, или установке указателей на NULL для скрытия двойных свободных» - более вероятно, что указатель после удаления устанавливается на NULL, чтобы вернуть его в состояние «сброса». Это совершенно допустимая семантика, и она использовалась задолго до того, как у нее были указатели ... которые имеют стоимость памяти, о которой Дэймон, похоже, не подозревает. Есть еще машины с конечной памятью, где такие вещи имеют значение. :-)
Jim Balter 10 нояб. 2014, в 20:19
4

JimBalter Это отличный момент, о котором @Damon, похоже, тоже не подозревает: ограничения имеют затраты, а C намеренно избегает многих ограничений явно из-за связанных с этим затрат. Удаление NULL вполне оправдано, если оно ускоряет медленную концепцию владения без потери безопасности (что во многих случаях очевидно). Зачем использовать более медленный механизм для безопасности, если он не дает никаких преимуществ?
Alice 10 нояб. 2014, в 21:02
1

Если повторное использование устаревших указателей всегда гарантировало немедленный сбой, я мог бы согласиться с рекомендацией @ Damon. Но память используется повторно, как в предсказуемом (стек), так и непредсказуемом (куча) местах. А ненулевые указатели могут передаваться и копироваться много раз, прежде чем они будут разыменованы, создавая скрытые псевдонимы и Heisenbugs различных ароматов вдали от места исходной проблемы. Мне пришлось отлаживать некоторые из этих ошибок в течение моей карьеры, и я твердо верю в то, чтобы как можно скорее сбросить устаревшие указатели на NULL, как основной шаг санитарии.
dewtell 24 март 2015, в 22:24
1

@Alice: я знаю, что это было какое-то время, но мне интересно читать вашу статью о попытках без блокировок, а также спрашивать, есть ли у вас github или подобное для других структур без блокировки?
dreamlax 18 март 2016, в 21:28
3

Интересно, куда попало предложение "перейти в чат" в этой ветке комментариев ...
Pockets 16 сен. 2016, в 04:11
0

@ Дэймон Полностью согласен. Установка указателя на nullptr также может иметь важные последствия для производительности. Например, если у вас есть древовидная структура данных и вы полагаетесь на рекурсию для удаления и решаете установить указатель на nullptr после вызова delete, стековые кадры не могут быть повторно использованы, как в хвостовой рекурсии. Много раз может быть достаточно, чтобы вызвать переполнение стека, если вы установите указатель на nullptr после удаления.
Curious 22 окт. 2016, в 18:44
1

ПРИМЕЧАНИЕ. Использование MACRO приведет к двойной оценке, если используется выражение . пример: my_delete(Order3PizzasAndBurnTheBakery())
WhiZTiM 03 фев. 2017, в 00:03
0

@WhiZTiM этот пример недопустим. Аргумент макроса должен быть lvalue, а вызов функции - нет, поэтому он не будет компилироваться. Но вы поняли. Для функции int** foo(void){static int *arr = new int(4); return &arr;} вызов my_delete(*foo()) выделит, удалит, затем выделит снова и, наконец, обнулит arr (нет указателей на выделенную память - утечка памяти). С другой стороны, my_delete(x) {auto _tmp = &(x); .. потерпит неудачу, если x - прямой вызов функции (не lvalue). Интересно, почему такой подверженный ошибкам код находится в принятом ответе?
Przemek 04 июнь 2018, в 22:15
0

@Przemek " Макро аргумент должен быть lvalue " ... Что? Это тривиально ложно. Макросы ничего не знают о категориях значений, объектах или каких-либо языковых особенностях; они просто безмозглые заменители. Аргумент макроса, содержащий текстовое представление вызова функции или любого другого выражения, будет подставлен в тело макроса, сколько раз этот аргумент встречается, и поэтому выражение будет оцениваться - и вызываться - столько раз, независимо от что возвращает вызов функции или какая категория значений имеет.
underscore_d 28 окт. 2018, в 13:28
0

@underscore_d ты вырвал мои слова из контекста, возможно, моя формулировка была не самой лучшей. Посмотрите на определение my_delete - после раскрытия макроса происходит присвоение аргументу макроса. Вы правы в том, что препроцессор макросов - это просто текстовый механизм, который просто скопирует и вставит определение, но результирующий код будет неправильным (во время компиляции).
Przemek 27 нояб. 2018, в 16:11

Показать ещё 31 комментарий