удаление массиву неправильного пути

Question

Можно создать дубликат:
How could pairing new[] with delete possibly lead to memory leak only?

Я всегда говорил, что это не безопасно для вызова удалять на массиве, наделенном новое []. Вы всегда должны сочетать новые с delete и new [] с delete [].

Так что я был удивлен, обнаружив, что следующий код компилируется и работает нормально, как в режиме отладки, так и в режиме Release под VS2008.

class CBlah 
{ 
public: 
    CBlah() : m_i(0) {} 

private: 
    int m_i; 
}; 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    for(;;) 
    { 
     CBlah * p = new CBlah[1000]; // with [] 
     delete p;     // no [] 
    } 
    return 0; 
} 

Это мне потребовалось некоторое время, чтобы выяснить, почему это работает на всех, и я думаю, что это просто везение, а некоторые неопределенное поведение.

BUT ... это заставило меня задуматься ... почему Visual Studio не забирает это, по крайней мере, в диспетчере памяти Debug? Это потому, что есть много кода, который делает эту ошибку, и они не хотят ее нарушать, или они чувствуют, что задача менеджера памяти Debug не в том, чтобы поймать такую ​​ошибку?

Любые мысли? Является ли это распространенным распространением?

Answer 1

Это неопределенное поведение и все в любви, войне и непредсказуемое поведение ... :)

Answer 2

Это работает, потому что особенности ++ библиотека времени выполнения C она была связана с использует ту же кучу, как для operator new и operator new[]. Многие это делают, но некоторые этого не делают, поэтому практика не рекомендуется.

Другая большая разница в том, что если CBlah был нетривиальный деструктор, то delete p; бы только назвать это первый объект в массиве, в то время как delete[] p; обязательно называть его для всех объектов.

Answer 3

Вы можете прочитать эти SO ответы и ссылки о delete и delete[]: About delete, operator delete, delete[], ...

Answer 4

Это, конечно, скомпилировать нормально, потому что нет никакой информации в указателе (во время компиляции), который будет видеть, если указатель указывает на массив или какие. Например:

int* p; 

cin>>x; 
if(x == 0) 
    p = new int; 
else 
    p = new int [10]; 

delete p; //correct or not? :) 

Теперь, о работе ОК. Это называется неопределенным поведением в C++, то есть нет никакой гарантии, что произойдет - все может работать нормально, вы можете получить segfault, вы можете получить просто неправильное поведение, или ваш компьютер может решить позвонить по телефону 911. UB < => нет гарантии

Answer 5

Согласно MDSN, при удалении массива он переводит delete, чтобы удалить []. (См., Например, there). Хотя вы должны иметь предупреждение после компиляции.

Answer 6

Причина, по которой Debug Memory Manager не воспринимает эту ошибку, вероятно, потому, что она не реализована на уровне нового/удаления, но на уровне менеджера памяти, который вызывается по new/delete to выделите требуемую память.
В этот момент различие между новым массивом и скалярным новым исчезло.

Answer 7

Я не знаю, что заставляет вас думать, что это «работает нормально». Он компилируется и завершается без сбоев.Это не означает, что не было никакой утечки или повреждения кучи. Кроме того, если на этот раз вам это удастся, это не обязательно сделает его безопасным.

Иногда даже переписывание буфера - это то, что вам «сойдет с рук», потому что байты, которые вы написали, не были использованы (возможно, это дополнение для выравнивания). Тем не менее, вы не должны обойти это.

Кстати, новый T [1] является формой нового [] и по-прежнему требует удаления [], хотя в этом случае есть только один элемент.

Answer 8

Интересная точка. Как только я просмотрел код и попытался убедить программистов исправить новое [] - удалить несоответствие. Я аргументировал себя «Элементом 5» от Effective C++ Скоттом Мейерсом. Тем не менее, они аргументировали словами: «Что вы хотите, это хорошо работает!» и доказал, что утечки памяти не было. Однако он работал только с POD-типами. Похоже, MS пытается исправить несоответствие, как указал Равелин.

Что произойдет, если вы добавите деструктор?

#include <iostream> 
class CBlah 
{ 
    static int instCnt; 
public: 
    CBlah() : m_i(0) {++instCnt;} 
    ~CBlah() 
    { 
     std::cout <<"d-tor on "<< instCnt <<" instance."<<std::endl; 
     --instCnt; 
    } 
private: 
    int m_i; 
}; 

int CBlah::instCnt=0; 

int main() 
{ 
    //for(;;) 
    { 
     CBlah * p = new CBlah[10]; // with [] 
     delete p;     // no [] 
    } 
    return 0; 
} 

Какое бы глупое исправление «интеллект» не было добавлено в VS, код не переносится.

Answer 9

Помните, что «работает правильно» находится во вселенной «неопределенного поведения». Вполне возможно, что конкретная версия конкретного компилятора реализовала это так, чтобы она работала во всех смыслах и целях. Важно помнить, что это не гарантируется, и вы действительно не можете быть уверены, что он работает на 100%, и вы не можете знать, что он будет работать со следующей версией компилятора. Он также не переносится, поскольку другой компилятор может работать по-другому.