Почему данный код валидный?

@NuMeRiC_ · Регистрация: 03.06.2019

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

Привет всем. Написал вот этот код на компиляторе clang новейшей версии:

C++

#include <iostream>
using namespace std;
 
class arr{
    char* data;
    public:
    arr(char* arr){cout<<"Ctor"<<endl;}
    ~arr(){
        cout<<"Dtor"<<endl;
        delete data;
    }
};
 
int main(){
    arr A(nullptr);
    A.~arr();
}

Освобождение памяти происходит 2 раза, это говорит и вывод в консоль:
Ctor
Dtor
Dtor
[Program finished]

Но никаких ошибок. В чем дело, ребята?

@hoggy · 02.01.2020, 22:55

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

В чем дело, ребята?

если явно не инициализировать указатель чем то осмысленным,
тогда он будет содержать мусор.

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

поэтому, даже неинициализированный указатель содержит нуль.
в этом случае твой код может отработать без ошибок.

однако, это не делает сам код валидным.
он по прежнему некорректен.

если комплировать visual studio - приложение упадёт с ошибкой.

@fao · 02.01.2020, 23:02

Не упадет, т.к. "The C++ language guarantees that delete p will do nothing if p is equal to NULL"

@hoggy · 02.01.2020, 23:06

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

Не упадет, т.к. "The C++ language guarantees that delete p will do nothing if p is equal to NULL"

с чего ты взял, что неинициализированный указатель будет содержать ноль?

на самом деле ещё как падает.

gcc
https://rextester.com/EUF58920

cl
https://rextester.com/OKWN18097

@NuMeRiC_ · 02.01.2020, 23:07 **[ТС]**

То есть при первом освобождении поинтер указывает на NULL, а значит второе его освобождение не приведет ни к чему, так?

@nyaka_wai · 02.01.2020, 23:15

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

с чего ты взял, что неинициализированный указатель будет содержать ноль?
на самом деле ещё как падает.
gcc
https://rextester.com/EUF58920
cl
https://rextester.com/OKWN18097

Нет ошибок в обоих вариантах, если в описании класса инициализировать указатель как

C++

1
2
3

char* data=nullptr;
или
char* data{};

Даже IDE на это намекает

А вариант ТСА у меня не крашится и отрабатывает в VS19. Мне тоже интересно было бы узнать, почему, инициализрованный нулем указатель можно удалять неограниченное число раз без ошибок, учитывая то, что после первой отработки деструктора, он уже может заполнятся мусором и следовательно критовать. Ведь мы же освобождаем память, занимаемую самим указателем, а никак не память, на которую ссылается указатель.

@fao · 02.01.2020, 23:21

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

То есть при первом освобождении поинтер указывает на NULL, а значит второе его освобождение не приведет ни к чему, так?

У Вас конструктор ничего не делает с указателем data. Но в VS (возможно не всегда) неинициализированный указатель становится равным NULL. Поэтому прога в VS не падает. Но в любом случае это плохая практика.

поэтому hoggy здесь абсолютно прав

@nyaka_wai · 02.01.2020, 23:30

А стоп я сам дурак. Мы же удаляем объект по заданному в указателе адресу, а не сам указатель. Надо спать идти

@fao · 02.01.2020, 23:35

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

А стоп я сам дурак. Мы же удаляем объект по заданному в указателе адресу, а не сам указатель. Надо спать идти

NULL можно удалять сколько угодно потому что с++ гарантирует, что ничего страшного не будет

@hoggy · 02.01.2020, 23:52

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

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

не может он заполняться мусором.

деструктор - это на самом деле самая обычная функция,
в которой обычно прописывают процедуру освобождения ресурсов.
но не более того.

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

и если твой объект хранит внутри себя нулевой указатель,
то этот указатель так же никуда не денется,
и по прежнему будет хранить ноль.

можешь хоть 10 раз вызывать деструктор - никакого мусора там по волшебству не образуется.

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

для автоматических объектов (как в случае ТС) такое волшебство начинается,
когда звершается область видимости имени объекта.

@nyaka_wai · 03.01.2020, 00:12

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

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

Еще раз спасибо, теперь я знаю больше ^__^

@TheCalligrapher · 03.01.2020, 01:17

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

Но никаких ошибок. В чем дело, ребята?

Этот код порождает неопределенное поведение по целому ряду причин. Никто вам не обещал, что неопределенное поведение будет проявляться в виде каких-то "ошибок". Неопределенное поведение может проявлять себя как угодно или не проявлять вообще. Вопросов типа "в чем дело" про неопределенное поведение нет и быть не может.

Вот и все объяснение.

С практической же точки зрения вам в данном случае просто случайно повезло. Мусор в вашем указателе случайно оказался нулем. Добавьте в функцию main парочку посторонних переменных и все накроется медным тазом.

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

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

Ничего подобного ни на каких "линуксах" нет и никогда не было.

@hoggy · 03.01.2020, 01:24

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

Ничего подобного ни на каких "линуксах" нет и никогда не было.

https://rextester.com/WWRH29370

тоже самое, только под виндой:
https://rextester.com/EWR23187

@TheCalligrapher · 03.01.2020, 01:35

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

https://rextester.com/WWRH29370

И? К чему здесь эти абсолютно ничего не значащие примеры?

http://coliru.stacked-crooked.... 3468843e46

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

@hoggy · 03.01.2020, 01:39

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

И? К чему здесь эти абсолютно ничего не значащие примеры?

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

@TheCalligrapher · 03.01.2020, 01:42

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

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

Ну то есть, вы обнаружили, что мусор в памяти - это мусор в памяти, то есть содержать он может что угодно, в том числе и нули.

Однако как из этого родилась чепуха про некие "зануления стековой памяти" - по-прежнему не ясно.

IGPIGP · 03.01.2020, 01:45

NuMeRiC_, в вашем вопросе два независимых подвопроса. Я убрал освобождение по непредсказуемому адресу и прэкспериментировал с пустым деструктором. Его вызов сам по себе безобиден. Потом я вспомнил, что при реинициализации при помощи placement new деструктор вызывают принудительно и циклы destructor/new(placementPtr) могут в одной области работать сколько угодно.

C++

#include <iostream>
using namespace std;
 
class arr{
    public:
    int data;
 
    arr(int data_=0):data(data_){cout<<"Ctor"<<endl;}
    ~arr(){
       if(data){
            cout<<"Dtor "<<data<<endl;
           --data;
           this->~arr();
        }
 
    }
};
int main()
{
arr A(1000);
A.~arr();
return 0;
}

Однако если выделить память по указателю а в деструкторе затребовать его освобождения то вызвать деструктор дважды подряд не получится. Может есть операционки которым это всё равно, но я не встречал.

@hoggy · 03.01.2020, 01:46

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

Я просто ума не приложу, как можно из очевидно бессмысленного эксперимента

мне очевидно, что в случае с gcc память на стеке содержит нули.

ты наверное думаешь, что это случайность?

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

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

Ну то есть, вы только что открыли, что мусор в памяти - это мусор в памяти, то есть содержать он может что угодно, в том числе и нули. На то он и мусор.
Однако как из этого родилась чепуха про некие "зануления стековой памяти" - по-прежнему не ясно.

в отличие от обычного мусора, в случае с gcc, нули - не случайность,
Бро.

@TheCalligrapher · 03.01.2020, 01:46

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

мне очевидно, что в случае с gcc память на стеке содержит нули.
ты наверное думаешь, что это случайность?

Я уже полностью опроверг ваше "очевидно" своим контрпримером. Нет, в случае с gcc память на стеке НЕ содержит нули.

IGPIGP · 03.01.2020, 01:50

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

зануления стековой памяти

Были бы дороговаты. Сообщество прокляло бы Линуса Торвальдса. Ещё раз прокляло бы.

@nyaka_wai 85 / 34 / 20 Регистрация: 15.12.2019 Сообщений: 88
	03.01.2020, 00:12	11
	Сообщение от hoggy не может он заполняться мусором. деструктор - это на самом деле самая обычная функция, в которой обычно прописывают процедуру освобождения ресурсов. но не более того. деструктор не уничтожает объект. после того, как деструктор уже отработал, объект никуда не девается. память, которую занимает объект, так же никуда не девается. и если твой объект хранит внутри себя нулевой указатель, то этот указатель так же никуда не денется, и по прежнему будет хранить ноль. можешь хоть 10 раз вызывать деструктор - никакого мусора там по волшебству не образуется. волшебство начинается когда освобождается память, которую когда-то занимал объект. только после этого память может быть перезаписана чем то иным. не раньше. для автоматических объектов (как в случае ТС) такое волшебство начинается, когда звершается область видимости имени объекта. Еще раз спасибо, теперь я знаю больше ^__^ 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	03.01.2020, 01:24	13
	Сообщение от TheCalligrapher Ничего подобного ни на каких "линуксах" нет и никогда не было. https://rextester.com/WWRH29370 тоже самое, только под виндой: https://rextester.com/EWR23187 0

@TheCalligrapher Вездепух 11696 / 6375 / 1724 Регистрация: 18.10.2014 Сообщений: 16,076
	03.01.2020, 01:35	14
	Сообщение от hoggy https://rextester.com/WWRH29370 И? К чему здесь эти абсолютно ничего не значащие примеры? http://coliru.stacked-crooked.... 3468843e46 Я просто ума не приложу, как можно из очевидно бессмысленного эксперимента сделать такой далеко идущий вывод про "при старте процесса вся его стековая память зануляется". Просто классическая диссертация Василия Ивановича наблюдается ("Вывод: у таракана уши располагаются на ногах"). 0

@TheCalligrapher Вездепух 11696 / 6375 / 1724 Регистрация: 18.10.2014 Сообщений: 16,076
	03.01.2020, 01:42	16
	Сообщение от hoggy эти примеры наглядно иллюстрируют, что в некоторых случаях память содержит нули. а в некоторых - не содержит. Ну то есть, вы обнаружили, что мусор в памяти - это мусор в памяти, то есть содержать он может что угодно, в том числе и нули. Однако как из этого родилась чепуха про некие "зануления стековой памяти" - по-прежнему не ясно. 1

Почему данный код валидный?

Решение

Решение

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	02.01.2020, 22:55	2
	Сообщение было отмечено NuMeRiC_ как решение Решение Сообщение от NuMeRiC_ В чем дело, ребята? если явно не инициализировать указатель чем то осмысленным, тогда он будет содержать мусор. однако, на некоторых системах (например на линуксах) при старте процесса вся его стековая память зануляется. это делается из соображений безопасности. поэтому, даже неинициализированный указатель содержит нуль. в этом случае твой код может отработать без ошибок. однако, это не делает сам код валидным. он по прежнему некорректен. если комплировать visual studio - приложение упадёт с ошибкой. 0

@fao 198 / 155 / 44 Регистрация: 11.11.2019 Сообщений: 345
	02.01.2020, 23:02	3
	Не упадет, т.к. "The C++ language guarantees that delete p will do nothing if p is equal to NULL" 1

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	02.01.2020, 23:06	4
	Сообщение от fao Не упадет, т.к. "The C++ language guarantees that delete p will do nothing if p is equal to NULL" с чего ты взял, что неинициализированный указатель будет содержать ноль? на самом деле ещё как падает. gcc https://rextester.com/EUF58920 cl https://rextester.com/OKWN18097 1

@NuMeRiC_ 3 / 3 / 0 Регистрация: 03.06.2019 Сообщений: 64
	02.01.2020, 23:07 [ТС]	5
	То есть при первом освобождении поинтер указывает на NULL, а значит второе его освобождение не приведет ни к чему, так? 0

@fao 198 / 155 / 44 Регистрация: 11.11.2019 Сообщений: 345
	02.01.2020, 23:21	7
	Сообщение от NuMeRiC_ То есть при первом освобождении поинтер указывает на NULL, а значит второе его освобождение не приведет ни к чему, так? У Вас конструктор ничего не делает с указателем data. Но в VS (возможно не всегда) неинициализированный указатель становится равным NULL. Поэтому прога в VS не падает. Но в любом случае это плохая практика. поэтому hoggy здесь абсолютно прав 0

@nyaka_wai 85 / 34 / 20 Регистрация: 15.12.2019 Сообщений: 88
	02.01.2020, 23:30	8
	А стоп я сам дурак. Мы же удаляем объект по заданному в указателе адресу, а не сам указатель. Надо спать идти 0

@fao 198 / 155 / 44 Регистрация: 11.11.2019 Сообщений: 345
	02.01.2020, 23:35	9
	Сообщение от nyaka_wai А стоп я сам дурак. Мы же удаляем объект по заданному в указателе адресу, а не сам указатель. Надо спать идти NULL можно удалять сколько угодно потому что с++ гарантирует, что ничего страшного не будет 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	02.01.2020, 23:52	10
	Сообщение от nyaka_wai Мне тоже интересно было бы узнать, почему, инициализрованный нулем указатель можно удалять неограниченное число раз без ошибок, учитывая то, что после первой отработки деструктора, он уже может заполнятся мусором и следовательно критовать. не может он заполняться мусором. деструктор - это на самом деле самая обычная функция, в которой обычно прописывают процедуру освобождения ресурсов. но не более того. деструктор не уничтожает объект. после того, как деструктор уже отработал, объект никуда не девается. память, которую занимает объект, так же никуда не девается. и если твой объект хранит внутри себя нулевой указатель, то этот указатель так же никуда не денется, и по прежнему будет хранить ноль. можешь хоть 10 раз вызывать деструктор - никакого мусора там по волшебству не образуется. волшебство начинается когда освобождается память, которую когда-то занимал объект. только после этого память может быть перезаписана чем то иным. не раньше. для автоматических объектов (как в случае ТС) такое волшебство начинается, когда звершается область видимости имени объекта. 1

@TheCalligrapher Вездепух 11696 / 6375 / 1724 Регистрация: 18.10.2014 Сообщений: 16,076
	03.01.2020, 01:17	12
	Сообщение от NuMeRiC_ Но никаких ошибок. В чем дело, ребята? Этот код порождает неопределенное поведение по целому ряду причин. Никто вам не обещал, что неопределенное поведение будет проявляться в виде каких-то "ошибок". Неопределенное поведение может проявлять себя как угодно или не проявлять вообще. Вопросов типа "в чем дело" про неопределенное поведение нет и быть не может. Вот и все объяснение. С практической же точки зрения вам в данном случае просто случайно повезло. Мусор в вашем указателе случайно оказался нулем. Добавьте в функцию `main` парочку посторонних переменных и все накроется медным тазом. Сообщение от hoggy однако, на некоторых системах (например на линуксах) при старте процесса вся его стековая память зануляется. это делается из соображений безопасности. Ничего подобного ни на каких "линуксах" нет и никогда не было. 1

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	03.01.2020, 01:39	15
	Сообщение от TheCalligrapher И? К чему здесь эти абсолютно ничего не значащие примеры? эти примеры наглядно иллюстрируют, что в некоторых случаях память содержит нули. а в некоторых - не содержит. 0

@hoggy 8739 / 4317 / 960 Регистрация: 15.11.2014 Сообщений: 9,760
	03.01.2020, 01:46	18
	Сообщение от TheCalligrapher Я просто ума не приложу, как можно из очевидно бессмысленного эксперимента мне очевидно, что в случае с gcc память на стеке содержит нули. ты наверное думаешь, что это случайность? Добавлено через 1 минуту Сообщение от TheCalligrapher Ну то есть, вы только что открыли, что мусор в памяти - это мусор в памяти, то есть содержать он может что угодно, в том числе и нули. На то он и мусор. Однако как из этого родилась чепуха про некие "зануления стековой памяти" - по-прежнему не ясно. в отличие от обычного мусора, в случае с gcc, нули - не случайность, Бро. 0

@TheCalligrapher Вездепух 11696 / 6375 / 1724 Регистрация: 18.10.2014 Сообщений: 16,076
	03.01.2020, 01:46	19
	Сообщение от hoggy мне очевидно, что в случае с gcc память на стеке содержит нули. ты наверное думаешь, что это случайность? Я уже полностью опроверг ваше "очевидно" своим контрпримером. Нет, в случае с gcc память на стеке НЕ содержит нули. 0

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 8950 / 4704 / 629 Регистрация: 04.12.2011 Сообщений: 13,999 Записей в блоге: 16
	03.01.2020, 01:50	20
	Сообщение от TheCalligrapher зануления стековой памяти Были бы дороговаты. Сообщество прокляло бы Линуса Торвальдса. Ещё раз прокляло бы. 0