delete[] статической памяти

@faridenco · Регистрация: 08.02.2013

Author24 — интернет-сервис помощи студентам

1. Должна ли возникать ошибка (или падение программы) при применении delete[] к статической памяти? У меня (Microsoft Visual Studio 2005) никаких ошибок не возникает. Но, просто, сталкивался с тем, что на некой 64-х разрядной машине (Windows), при запуске моей 32-х разрядной программы (то есть в эмуляторе) она вылетала в месте где используется delete[] к статической переменной. А также встречал в интернете вопросы о ошибке при delete[] статической памяти, но там не указывался компилятор.

2. Если вылетание при delete[] статической памяти возможно, то как узнать какой указатель: на динамическую память или статическую. Теоретически мне это не предсnавляется сложным. Если этого нету в C/C++, то может такая возможность есть в WinApi?
Вот, например, есть в функция в которую передается char*. И эта память освобождается в функции. Но в функцию ведь может быть передана и константа и указатель на статическую память.

@Toshkarik · 20.05.2013, 20:17

Сообщение от faridenco

Потому что так короче и удобней, умник.

Держите свои эмоции при себе, не переходите на личности.
Не ответили на вопрос потому что ответ на него есть в любой более или менее приличной книге по C++ для начинающих. В частности говорится о том, что память под статические объекты выделяется при запуске программы, и освобождается при ее завершении, никакие delete ее не освободят.
http://en.wikipedia.org/wiki/Data_segment

A data segment is a portion of virtual address space of a program, which contains the global variables and static variables that are initialized by the programmer. The size of this segment is determined by the values placed there by the programmer before the program was compiled or assembled, and does not change at run-time.

Добавлено через 2 минуты

Сообщение от faridenco

Поначалу писали что это ошибка, а оказалось что стандарт это не определяет как ошибку.

Смотря что подразумевать под ошибкой. Данный код ошибочен, так как это чистый UB, он не соответствует стандарту. Не нужно рассчитывать в этом случае на компилятор, в следующей версии поведение может кардинально измениться.

Убежденный · 20.05.2013, 20:18

Сообщение от faridenco

Поначалу писали что это ошибка, а оказалось что стандарт это не определяет как ошибку.

Стандартом это квалифицируется, как неопределенное поведение (undefined behavior, UB).
Разве этого не достаточно ?

Сообщение от faridenco

Впрочем я итак знаю, что программа, скомпилированная компилятором Microsoft, ничего не делает когда встречает delete[] по отношению к статической памяти.

Это не так.
Попробуйте, например, вызвать "operator delete []" на адресе
какой-нибудь статической или глобальной переменной.
Скорее всего, получите разрушение кучи (heap corruption).

@faridenco · 20.05.2013, 20:39 **[ТС]**

Сообщение от Toshkarik

Держите свои эмоции при себе, не переходите на личности.
Не ответили на вопрос потому что ответ на него есть в любой более или менее приличной книге по C++ для начинающих. В частности говорится о том, что память под статические объекты выделяется при запуске программы, и освобождается при ее завершении, никакие delete ее не освободят.
http://en.wikipedia.org/wiki/Data_segment

Добавлено через 2 минуты

Смотря что подразумевать под ошибкой. Данный код ошибочен, так как это чистый UB, он не соответствует стандарту. Не нужно рассчитывать в этом случае на компилятор, в следующей версии поведение может кардинально измениться.

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

Добавлено через 9 минут

Сообщение от Убежденный

Попробуйте, например, вызвать "operator delete []" на адресе
какой-нибудь статической или глобальной переменной.
Скорее всего, получите разрушение кучи (heap corruption).

Я еще в первом посте написал, что в реализациях от Micrsoft я такого не замечал. Я указал свой компилятор. Что мне пробовать, когда я так везде пишу на своем компиляторе, еще ни одна программа не вылетала. Падала только при запуске на эмуляторе, в 64-х битной винде (32-х битная программа). Впроем и о этом я уже писал.

Добавлено через 7 минут

Стандартом это квалифицируется, как неопределенное поведение (undefined behavior, UB).

Это означает, что стандартом поведение не определено, а не то что поведение программы непредсказуемо ). Это означает, что разработчик компилятор сам решает как обработать эту ситуацию. То есть все зависит от реализации.
Вот пример я уже привел. В реализации от Microsoft ничего не делается. Куча повреждается если пишешь в динамическую память по адресу, не выделенному оператором new.

Убежденный · 20.05.2013, 20:52

C++

#include <iostream>
 
int value = 123;
 
int main()
{
    delete [] &value;
    std::cout << value << std::endl;
    return 0;
}

Отладочная версия вылетает с сообщением "Debug Assertion Failed (_BLOCK_TYPE_IS_VALID).
Релизная версия вылетает с исключением 0xC0000374 (Heap Corruption).
Проверил на VC++ 2008/2010/2012.

@faridenco · 20.05.2013, 21:05 **[ТС]**

Сообщение от Убежденный

C++

#include <iostream>
 
int value = 123;
 
int main()
{
    delete [] &value;
    std::cout << value << std::endl;
    return 0;
}

Отладочная версия вылетает с сообщением "Debug Assertion Failed (_BLOCK_TYPE_IS_VALID).
Релизная версия вылетает с исключением 0xC0000374 (Heap Corruption).
Проверил на VC++ 2008/2010/2012.

Мой компилятор (Microsoft Visual Studio 2005) в дебаге не выдал никаких ошибок. Благодарю, что вы пишите по теме. Именно это мне и было интересно узнать. То есть, на сколько Microsoft придерживается определенному правилу в своей реализации. Теперь я знаю, что в других компиляторах Microsoft будет ошибка.

Добавлено через 5 минут
И в релизе тоже разумеется у меня ошибок нет.

Убежденный · 20.05.2013, 21:29

Давайте вернемся к тому, с чего начали.

Сообщение от faridenco

1. Должна ли возникать ошибка (или падение программы) при применении delete[] к статической памяти?

Согласно стандарту, не должна. Но указывается, что в этом случае поведение не определено.
То есть, в зависимости от комбинации "компилятор-платформа" и других факторов, может
возникнуть все, что угодно - от "замалчивания", которое наблюдается на VC++ 2005, до
выбрасывания исключений и порчи данных.

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

C++

#include <iostream>
 
 
 
class foo
{
public:
    foo()
    {
        std::cout << "create" << std::endl;
    }
 
    ~foo()
    {
        std::cout << "destroy" << std::endl;
    }
};
 
 
 
foo *create_foo()
{
    return (new foo());
}
 
void destroy_foo(void *pFoo)
{
    delete pFoo;
}
 
 
 
int main()
{
    foo *pFoo = create_foo();
    destroy_foo(pFoo);
    return 0;
}

Вывод данной программы (VC++ 2012):

> create

Как видим, деструктор foo не был вызван.
Кстати, не удивляйтесь, если на каком-то компиляторе эта программа завершится с ошибкой
или повиснет, так как это тоже undefined behavior.

И я могу объяснить, почему Стандартом здесь не предусмотрен выброс какого-нибудь исключения,
что было бы благом. Причина - оптимизация. Указатели хранят лишь адрес ячейки памяти, без
информации о типах и тому подобного. Подразумевается, что программист сам следит за
правильным удалением объектов и "не платит за то, что не использует".

Сообщение от faridenco

2. Если вылетание при delete[] статической памяти возможно, то как узнать какой указатель: на динамическую память или статическую.

Никак.
Этот вопрос решается на другом уровне - "политика владения".
Обычно на уровне всего исходного кода проекта поддерживается ряд ограничений по поводу
того, какие функции могут создавать и удалять объекты, а какие нет.
Например, функция, принимающая указатель, обычно не освобождает его, оставляя это на
совести вызывающего кода. Это один из простейших паттернов владения объектами.
Кроме этого, вместо "голых" указателей надежнее применять смарт-поинтеры и программные
интерфейсы, самостоятельно реализующие управление временем жизни объектов. Например,
подсчет ссылок. Это очень распостраненный подход на C++, где есть такие вещи, как RAII.
Количество ошибок, связанных с управлением памятью, при таком подходе сильно снижается.

@faridenco · 20.05.2013, 21:36 **[ТС]**

Да, я осведомлен о smart-pointer-х. Просто ищу способы как обходится без них.

alsav22 · 20.05.2013, 21:36

Убежденный, зачем здесь delete для массива?

Убежденный · 20.05.2013, 21:42

Сообщение от alsav22

Убежденный, зачем здесь delete для массива?

"Здесь" - это где именно ?

alsav22 · 20.05.2013, 21:47

Сообщение от Убежденный

"Здесь" - это где именно ?

C++

 
#include <iostream>
 
int value = 123;
 
int main()
{
    delete [] &value;
    std::cout << value << std::endl;
    return 0;
}

Убежденный · 20.05.2013, 21:50

Взято из вопроса топикстартера:

Сообщение от faridenco

1. Должна ли возникать ошибка (или падение программы) при применении delete[] к статической памяти?

@daslex · 20.05.2013, 22:15

Сообщение от faridenco

Значит тогда "динамической памяти" тоже нету

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

Не по теме:

и вообще раздули из мухи слона

@faridenco · 20.05.2013, 23:35 **[ТС]**

Сообщение от daslex

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

Не по теме:

и вообще раздули из мухи слона

Это был риторический вопрос. Термин "динамическая память" употребляется к языкам програмирования. А на твою писанину для дедсада мне наплевать.

@daslex · 20.05.2013, 23:38

faridenco, тебе еще на первых двух страницах сказали ответ, дедуля.

@faridenco · 20.05.2013, 23:44 **[ТС]**

Сообщение от daslex

faridenco, тебе еще на первых двух страницах сказали ответ, дедуля.

Советую в таком случае внимательно все перечитать.
А вообще ответ не дан до сих пор. Я спрашивал про реализации (компиляторы). Более менее имею представление о компилторах Microsoft. А об этом мне ответили на третьей странице. Ни о каких больше реализациях мне не отвечали.
Но, то что это не ошибка, а поведение зависит от реализации - это точно.

@daslex · 20.05.2013, 23:53

faridenco, очки надень и посмотри

Добавлено через 8 минут

Сообщение от faridenco

1. Должна ли возникать ошибка (или падение программы) при применении delete[] к статической памяти? У меня (Microsoft Visual Studio 2005) никаких ошибок не возникает. Но, просто, сталкивался с тем, что на некой 64-х разрядной машине (Windows), при запуске моей 32-х разрядной программы (то есть в эмуляторе) она вылетала в месте где используется delete[] к статической переменной. А также встречал в интернете вопросы о ошибке при delete[] статической памяти, но там не указывался компилятор.
2. Если вылетание при delete[] статической памяти возможно, то как узнать какой указатель: на динамическую память или статическую. Теоретически мне это не предсnавляется сложным. Если этого нету в C/C++, то может такая возможность есть в WinApi?
Вот, например, есть в функция в которую передается char*. И эта память освобождается в функции. Но в функцию ведь может быть передана и константа и указатель на статическую память.

Где?

Сообщение от faridenco

Я спрашивал про реализации (компиляторы)

@faridenco · 20.05.2013, 23:54 **[ТС]**

Сообщение от daslex

faridenco, очки надень и посмотри

По первому посту ясно, что меня интересует поведение программы при delete[] статической памяти. И что на моем компиляторе нет ошибок. А значит нужна информация о реализациях. Ответ поведение зависит от реализации (undefined behavior) - не ответ.

На первой странице я уточнил (когда мне все еще твердили, что это ошибка).

Поэтому и спрашиваю, как на это смотрит стандарт, как это отрабатывает компилятор Microsoft и пр.

@grizlik78 · 21.05.2013, 00:06

Сообщение от faridenco

Но, то что это не ошибка, а поведение зависит от реализации - это точно.

Поведение зависит от реализации — это implementation defined, на худой конец
unspecified behavior. А undefined behavior говорит о том, что реализации может вообще никакой не быть, то есть разработчику компилятора не стоит думать о поведении. Поведение непредсказуемо. Несколько запусков одной и той же программы могут давать разное поведение (но разумеется не обязаны).
Само использование "undefined behavior" — это и есть ошибка. Не синтаксическая, а семантическая.

@daslex · 21.05.2013, 00:07

Сообщение от faridenco

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

Сообщение от alsav22

Как реагирует компилятор на такое освобождение неважно, в любом случае это ошибка.

Сообщение от Croessmah

На процесс компиляции это никак не повлияет - за такими вещами следит программист, а не компилятор.

Сообщение от Croessmah

Рано или поздно упадет, если, конечно же при компиляции Ваш код не был вырезан

Сообщение от taras atavin

По идее должна, так как эта же память потом будет освобождена ещё раз неявно, но винда врядли способна это гарантировать.

Вам еще на первой странице в один голос твердили, что упадет, что ошибка, что нельзя, но вы считаете себя умнее всех

@faridenco · 21.05.2013, 00:19 **[ТС]**

daslex, ЭТО НЕ ОШИБКА. Перечитай всю ветку и не тормози (или хотя бы мои сообщения).

Добавлено через 6 минут

Само использование "undefined behavior" — это и есть ошибка

Это означает, что поведение стандартом не определено.
И в этой ветке приводили примеры, когда один и тот же код с delete[] или вызывал оишбку или нет, в зависимости от реализации. Хотя по стандарту undefined behavior.
Есть величины размеры которых зависят от реализации, к ним употребляется термин implementation defined.

@faridenco 0 / 0 / 0 Регистрация: 08.02.2013 Сообщений: 26
	20.05.2013, 21:36 [ТС]	27
	Да, я осведомлен о smart-pointer-х. Просто ищу способы как обходится без них. 0

alsav22 5498 / 4893 / 831 Регистрация: 04.06.2011 Сообщений: 13,587
	20.05.2013, 21:36	28
	Убежденный, зачем здесь delete для массива? 1

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	20.05.2013, 21:50	31
	Взято из вопроса топикстартера: Сообщение от faridenco 1. Должна ли возникать ошибка (или падение программы) при применении delete[] к статической памяти? 1

@faridenco 0 / 0 / 0 Регистрация: 08.02.2013 Сообщений: 26
	20.05.2013, 23:35 [ТС]	33
	Сообщение от daslex Динамической нету. Есть динамически распределяемая, которая распределяется на что-то, сама память не расширяется, сколько она вмещает, столько и будет вмещать, больше в нее не засунешь. Не по теме: и вообще раздули из мухи слона Это был риторический вопрос. Термин "динамическая память" употребляется к языкам програмирования. А на твою писанину для дедсада мне наплевать. 0

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,882
	20.05.2013, 23:38	34
	faridenco, тебе еще на первых двух страницах сказали ответ, дедуля. 0

@faridenco 0 / 0 / 0 Регистрация: 08.02.2013 Сообщений: 26
		1
	delete[] статической памяти 18.05.2013, 03:56. Показов 7285. Ответов 45 Метки нет (Все метки) 1. Должна ли возникать ошибка (или падение программы) при применении delete[] к статической памяти? У меня (Microsoft Visual Studio 2005) никаких ошибок не возникает. Но, просто, сталкивался с тем, что на некой 64-х разрядной машине (Windows), при запуске моей 32-х разрядной программы (то есть в эмуляторе) она вылетала в месте где используется delete[] к статической переменной. А также встречал в интернете вопросы о ошибке при delete[] статической памяти, но там не указывался компилятор. 2. Если вылетание при delete[] статической памяти возможно, то как узнать какой указатель: на динамическую память или статическую. Теоретически мне это не предсnавляется сложным. Если этого нету в C/C++, то может такая возможность есть в WinApi? Вот, например, есть в функция в которую передается char*. И эта память освобождается в функции. Но в функцию ведь может быть передана и константа и указатель на статическую память. 0

@Toshkarik 1181 / 894 / 94 Регистрация: 03.08.2011 Сообщений: 2,461
	20.05.2013, 20:17	21
	Сообщение от faridenco Потому что так короче и удобней, умник. Держите свои эмоции при себе, не переходите на личности. Не ответили на вопрос потому что ответ на него есть в любой более или менее приличной книге по C++ для начинающих. В частности говорится о том, что память под статические объекты выделяется при запуске программы, и освобождается при ее завершении, никакие delete ее не освободят. http://en.wikipedia.org/wiki/Data_segment A data segment is a portion of virtual address space of a program, which contains the global variables and static variables that are initialized by the programmer. The size of this segment is determined by the values placed there by the programmer before the program was compiled or assembled, and does not change at run-time. Добавлено через 2 минуты Сообщение от faridenco Поначалу писали что это ошибка, а оказалось что стандарт это не определяет как ошибку. Смотря что подразумевать под ошибкой. Данный код ошибочен, так как это чистый UB, он не соответствует стандарту. Не нужно рассчитывать в этом случае на компилятор, в следующей версии поведение может кардинально измениться. 1

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	20.05.2013, 20:18	22
	Сообщение от faridenco Поначалу писали что это ошибка, а оказалось что стандарт это не определяет как ошибку. Стандартом это квалифицируется, как неопределенное поведение (undefined behavior, UB). Разве этого не достаточно ? Сообщение от faridenco Впрочем я итак знаю, что программа, скомпилированная компилятором Microsoft, ничего не делает когда встречает delete[] по отношению к статической памяти. Это не так. Попробуйте, например, вызвать "operator delete []" на адресе какой-нибудь статической или глобальной переменной. Скорее всего, получите разрушение кучи (heap corruption). 1

@faridenco 0 / 0 / 0 Регистрация: 08.02.2013 Сообщений: 26
	20.05.2013, 20:39 [ТС]	23
	Сообщение от Toshkarik Держите свои эмоции при себе, не переходите на личности. Не ответили на вопрос потому что ответ на него есть в любой более или менее приличной книге по C++ для начинающих. В частности говорится о том, что память под статические объекты выделяется при запуске программы, и освобождается при ее завершении, никакие delete ее не освободят. http://en.wikipedia.org/wiki/Data_segment Добавлено через 2 минуты Смотря что подразумевать под ошибкой. Данный код ошибочен, так как это чистый UB, он не соответствует стандарту. Не нужно рассчитывать в этом случае на компилятор, в следующей версии поведение может кардинально измениться. Я прекрасно осведомлен как устроена память, как она выделяется и освобождается. Я знаю, что delete[] не освобождает статическую и автоматическую память. Вопрос мой совсем был не об этом. Перечитай мои сообщения. Добавлено через 9 минут Сообщение от Убежденный Попробуйте, например, вызвать "operator delete []" на адресе какой-нибудь статической или глобальной переменной. Скорее всего, получите разрушение кучи (heap corruption). Я еще в первом посте написал, что в реализациях от Micrsoft я такого не замечал. Я указал свой компилятор. Что мне пробовать, когда я так везде пишу на своем компиляторе, еще ни одна программа не вылетала. Падала только при запуске на эмуляторе, в 64-х битной винде (32-х битная программа). Впроем и о этом я уже писал. Добавлено через 7 минут Стандартом это квалифицируется, как неопределенное поведение (undefined behavior, UB). Это означает, что стандартом поведение не определено, а не то что поведение программы непредсказуемо ). Это означает, что разработчик компилятор сам решает как обработать эту ситуацию. То есть все зависит от реализации. Вот пример я уже привел. В реализации от Microsoft ничего не делается. Куча повреждается если пишешь в динамическую память по адресу, не выделенному оператором new. 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	20.05.2013, 21:42	29
	Сообщение от alsav22 Убежденный, зачем здесь delete для массива? "Здесь" - это где именно ? 0

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,882
	20.05.2013, 22:15	32
	Сообщение от faridenco Значит тогда "динамической памяти" тоже нету Динамической нету. Есть динамически распределяемая, которая распределяется на что-то, сама память не расширяется, сколько она вмещает, столько и будет вмещать, больше в нее не засунешь. Не по теме: и вообще раздули из мухи слона 0

@faridenco 0 / 0 / 0 Регистрация: 08.02.2013 Сообщений: 26
	20.05.2013, 23:44 [ТС]	35
	Сообщение от daslex faridenco, тебе еще на первых двух страницах сказали ответ, дедуля. Советую в таком случае внимательно все перечитать. А вообще ответ не дан до сих пор. Я спрашивал про реализации (компиляторы). Более менее имею представление о компилторах Microsoft. А об этом мне ответили на третьей странице. Ни о каких больше реализациях мне не отвечали. Но, то что это не ошибка, а поведение зависит от реализации - это точно. 0

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,882
	20.05.2013, 23:53	36
	faridenco, очки надень и посмотри Добавлено через 8 минут Сообщение от faridenco 1. Должна ли возникать ошибка (или падение программы) при применении delete[] к статической памяти? У меня (Microsoft Visual Studio 2005) никаких ошибок не возникает. Но, просто, сталкивался с тем, что на некой 64-х разрядной машине (Windows), при запуске моей 32-х разрядной программы (то есть в эмуляторе) она вылетала в месте где используется delete[] к статической переменной. А также встречал в интернете вопросы о ошибке при delete[] статической памяти, но там не указывался компилятор. 2. Если вылетание при delete[] статической памяти возможно, то как узнать какой указатель: на динамическую память или статическую. Теоретически мне это не предсnавляется сложным. Если этого нету в C/C++, то может такая возможность есть в WinApi? Вот, например, есть в функция в которую передается char. И эта память освобождается в функции. Но в функцию ведь может быть передана и константа и указатель на статическую память. Где? Сообщение от faridenco* Я спрашивал про реализации (компиляторы) 0

@faridenco 0 / 0 / 0 Регистрация: 08.02.2013 Сообщений: 26
	20.05.2013, 23:54 [ТС]	37
	Сообщение от daslex faridenco, очки надень и посмотри По первому посту ясно, что меня интересует поведение программы при delete[] статической памяти. И что на моем компиляторе нет ошибок. А значит нужна информация о реализациях. Ответ поведение зависит от реализации (undefined behavior) - не ответ. На первой странице я уточнил (когда мне все еще твердили, что это ошибка). Поэтому и спрашиваю, как на это смотрит стандарт, как это отрабатывает компилятор Microsoft и пр. 0

@grizlik78 2381 / 1665 / 279 Регистрация: 29.05.2011 Сообщений: 3,399
	21.05.2013, 00:06	38
	Сообщение было отмечено как решение Решение Сообщение от faridenco Но, то что это не ошибка, а поведение зависит от реализации - это точно. Поведение зависит от реализации — это implementation defined, на худой конец unspecified behavior. А undefined behavior говорит о том, что реализации может вообще никакой не быть, то есть разработчику компилятора не стоит думать о поведении. Поведение непредсказуемо. Несколько запусков одной и той же программы могут давать разное поведение (но разумеется не обязаны). Само использование "undefined behavior" — это и есть ошибка. Не синтаксическая, а семантическая. 5

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,882
	21.05.2013, 00:07	39
	Сообщение от faridenco Вопрос был не только про компилятор, а про работу программы, уже скомпилированной (может ли она падать). Сообщение от alsav22 Как реагирует компилятор на такое освобождение неважно, в любом случае это ошибка. Сообщение от Croessmah На процесс компиляции это никак не повлияет - за такими вещами следит программист, а не компилятор. Сообщение от Croessmah Рано или поздно упадет, если, конечно же при компиляции Ваш код не был вырезан Сообщение от taras atavin По идее должна, так как эта же память потом будет освобождена ещё раз неявно, но винда врядли способна это гарантировать. Вам еще на первой странице в один голос твердили, что упадет, что ошибка, что нельзя, но вы считаете себя умнее всех 0

@faridenco 0 / 0 / 0 Регистрация: 08.02.2013 Сообщений: 26
	21.05.2013, 00:19 [ТС]	40
	daslex, ЭТО НЕ ОШИБКА. Перечитай всю ветку и не тормози (или хотя бы мои сообщения). Добавлено через 6 минут Само использование "undefined behavior" — это и есть ошибка Это означает, что поведение стандартом не определено. И в этой ветке приводили примеры, когда один и тот же код с delete[] или вызывал оишбку или нет, в зависимости от реализации. Хотя по стандарту undefined behavior. Есть величины размеры которых зависят от реализации, к ним употребляется термин implementation defined. 0

delete[] статической памяти

Решение