Можно ли Конструктор и Деструктор вызывать как метод класса?

@Artem_Pv · Регистрация: 31.03.2019

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

Собственно вопрос:
можно ли Конструктор и Деструктор вызывать вручную, как обычный метод класса?
Например, я хочу управлять очередностью вызовов. См. пример:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class FirstClass   
{
public:
    FirstClass()
    {
    }
};
 
class SecondClass : public FirstClass   
{
public:
    SecondClass()
    {
      // ...
 
      FirstClass ();  // А здесь его можно вызвать?  
    }
 };

@Azawa · 30.06.2019, 22:17

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

ога... только вот кто вам разрешит напрямую распоряжаться памятью? это же ось на этом уровне командует парадом?

Динамически выделяемой памятью да, ОС перекроет доступ если ее освободить.
А если объект находится в стеке?

IGPIGP · 30.06.2019, 22:21

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

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

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

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

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

Динамически выделяемой памятью да, ОС перекроет доступ если ее освободить.

Опять-таки. Ни кто не собирается вызывать delete на указателе. А прямой вызов деструктора на указателе ptr_obj->~MyClass(); не освободит память. А потом placement new. В принципе и тут и на стеке, нет разницы.

@hoggy · 30.06.2019, 22:21

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

а как же адреса и ссылки которые содержал объект (вообще конструкторы могут быть разные и инварианты тоже), они же не всегда могут быть одинаковые между двумя вызовами конструктора?

а при чем здесь вообще адреса и ссылки, которые содержит объект?

вот например:

C++
1
2
std::string v = "hello ";  // 1
v += "world";  // 1

после модификации строки,
внутренние данные объекта очевидно изменились.

ну и что? объект перестал быть самим собой?

другой пример:

стандарт говорит, что ежели объект переместить (std::move),
то он должен оказаться в unspecified состоянии.

unspecified состояние - это ситуация,
когда точно не известно чем будет заполнена память.
и не известно в каком логическом состоянии находится объект.
однако известно, что:

- обязан корректно работать деструктор
опустошенный объект должен суметь корректно разрушиться.

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

пример:

C++
1
2
3
4
5
6
7
8
9
10
11
12
std::string v = "hello";
 
occupy(std::move(v)); //<--- перемещаем
 
// <--- вот здесь объект unspecified 
// нельзя знать наверняка 
// в каком состоянии находятся внутренние данные объекта
 
v = "world"; 
 
// <--- вот здесь объект в согласованном состоянии
// и точно известно, что он содержит строку "world"

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

фокус же в том, что технически,
процедура присвоения объекту нового состояния ничем не отличается
от "воскрешения" объекта при помощи new placement.

IGPIGP · 30.06.2019, 22:23

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

а при чем здесь вообще адреса и ссылки, которые содержит объект?

Всё верно. Состояние объекта и объект не одно и то же самое.

@hoggy · 30.06.2019, 22:25

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

только вот кто вам разрешит напрямую распоряжаться памятью?

киллер-фича с/с++ - прямой доступ к памяти.

@_stanislav · 30.06.2019, 22:35

hoggy, допустим
1 ты сконструировал объект на каком то адресе не суть.
2 что то поделал с этим объектом
3 сломал его деструктором и по новой сконструировал его на том же адресе.
где гарантии что все его прежние зависимости восстановятся в состоянии 2?

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

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

Состояние объекта и объект не одно и то же самое.

состояние объекта это часть объекта.

Добавлено через 2 минуты
hoggy, троллишь ты по ходу дела просто.

IGPIGP · 30.06.2019, 22:41

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

где гарантии что все его прежние зависимости восстановятся в состоянии 2?

Гарантии те же что и при конструировании его изначально. Если первое конструирование + жизненный промежуток не изменили состояние объекта и окружения необратимо.
А кто даёт гарантии при конструировании как таковом? Оно гарантировано настолько насколько оно возможно. Но не более. И слова ломать и конструировать ломают восприятие. Инициализация и деинициализация соответствуют по смыслу. А речь о том считать ли оба объекта одним и тем же объектом. Вопрос холиварный. Однако, математическая мания ломать свои же абстракции доводя их до абсурда это единственная закономерность.
_stanislav, вот ссылка:

C++
1
2
3
4
5
A a;
A& ra(a);
a.~A();
new(&a) A();
//ссылка смотрит в новый объект или в тот же?

?

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

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

hoggy, троллишь ты по ходу дела просто.

Твой слог магистра Йода слог напоминать начал.

Да пребудет с тобой ссылка. Вопрос о ней не троллинг отнюдь.

@Azawa · 30.06.2019, 22:49

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

Обязан ли деструктор никогда не очищать память, или некоторые компиляторы могут реализовать самоочистку памяти нулями? Или, может конструктор в какой-то момент поместить поля класса в другом порядке? Я не знаю, поэтому сомневаюсь в надежности.

@_stanislav · 30.06.2019, 22:51

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

Твой слог магистра Йода слог напоминать начал.

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

//ссылка смотрит в новый объект или в тот же?

естественно в новый.

был вызван деструктор, был вызван конструктор.

IGPIGP · 30.06.2019, 23:00

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

естественно в новый.

Это философский момент. С этого момента ты на той стороне ссылки которая считает что у ссылки есть другая сторона. А я остаюсь на этой.

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

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

Нет. Если объект реинициализирован, то не он ни тот кто к нему обращается не могут определить старый он или новый если данные идентичны. И даже если данные не идентичны, то состояние не идентифицирует объект всё едино. Вот если Вы изменяете поле объекта, Вы же не считаете, что получаете новый объект? Греческое: "Никто не может дважды войти в одну и ту же ~~реку~~ переменную" оставим грекам.

@hoggy · 30.06.2019, 23:02

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

где гарантии что все его прежние зависимости восстановятся в состоянии 2?

ты сам понял, о чем спросил?

@_stanislav · 30.06.2019, 23:02

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

Это философский момент.

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

IGPIGP · 30.06.2019, 23:08

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

это тот же дом или нет?

Он тот же ровно на столько, насколько ты не можежешь его отличить от прежнего. Однако на пальцах это трудно. Сравнивать объекты с пальцами, домами, слонами в данном контексте, это приём не удачный.

@_stanislav · 30.06.2019, 23:11

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

@zayats80888 · 30.06.2019, 23:23

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

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

исходя из этой логики, если вызвать для него какой-нить метод, меняющий состояние(operator= например), его тоже нельзя использовать как прежде, но это все тот же объект.

IGPIGP · 30.06.2019, 23:26

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

нельзя конструировать на его же месте новый объект и использовать его как старый

это твоя фантазия и ты видишь её не состоятельность. Поэтому

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

тема меня утомила

но не стоит добавлять сложностей. Можно/нельзя, это новый виток. Мы сейчас в точке, где мнения о объекте старом/новом разделились. Комитет по стандартизации сочинил длинную историю о том что делают объекты и что можно сделать с объектами. Потому, что сегодня дать определение кратко и сухо они не могут. Наверное потому, что абстракция утратила логическую консистентность. А может просто не хотят. На этом мнения и разделились. А вот о можно и нельзя, - другая тема. На самом деле - можно. Вопрос не в этом.

@rat0r · 30.06.2019, 23:45

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

естественно в новый.

Не обязательно. См. https://timsong-cpp.github.io/... sic.life#8

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

Это философский момент.

Для тех, кто не читал что по ссылке.

@hoggy · 01.07.2019, 00:21

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

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

религия не позволяет?

IGPIGP · 01.07.2019, 00:29

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

Для тех, кто не читал что по ссылке.

Читал. И не вижу различий между старым и новым объектом, кроме экзальтированного призыва считать переинициализированный объект новым.
rat0r, я не беру во внимание случаи наличия статического счётчика сконструированных объектов и константной переменной экземпляра фиксирующей номер данного объекта в момент его инициализации. Такой приём, действительно может создать барьер между старыми и новыми объектами, но он не кажется мне убедительным. Не только потому, что счётчик переполняем. Потому, что понятие объекта изначально замыслено как базовое понятие RAII и это значительно более низкоуровневая абстракция. Другое дело, что можно разрешить компиляторщикам играть и с объектами.
В плохую погоду бывают кошмарные сны и они вещают, о супер вирусной эпидемии, мировой войне и... и даже виртуальной машине С++

Близится пришествие неизбежного. имхо.

@Fulcrum_013 · 01.07.2019, 00:30

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

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

А коммитет то не в курсе. И все контейнеры налепили так что они на старом месте удаленных новые инстансы констрактят. Ой ойо шо буде.... весь софт на плюсах вооще работать не может....

Новые блоги и статьи Все статьи Все блоги /
Локальный http сервер Argus19 17.10.2026 Локальный http сервер На работе, на двух локальных компьютерах круглосуточно работают программы опроса приборов с записью в книги Excel,которые раз в сутки записываются на сервер компании. Т. к. . . .	Копировать Windows на новый диск на UEFI damix 17.10.2026 https:/ / uriesk. wordpress. com/ 2016/ 11/ 01/ move-window-10-to-ssd-on-a-uefi-dualboot-system-with-basic-linux-tools/ TL DR Вставляем диск, а старый подключаем через переходник, грузимся с лайва. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .
Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .

@Azawa Отпрыск ChatGPT 266 / 31 / 4 Регистрация: 18.06.2019 Сообщений: 155
	30.06.2019, 22:49
	IGPIGP, а, ну да получается. Все равно как-то логичнее считать данные объекта мусором после вызова деструктора и не использовать их в дальнейшем, даже если на них построен новый объект такого же типа. Как-то, надежность такого повторного использования данных не вызывает доверия. Обязан ли деструктор никогда не очищать память, или некоторые компиляторы могут реализовать самоочистку памяти нулями? Или, может конструктор в какой-то момент поместить поля класса в другом порядке? Я не знаю, поэтому сомневаюсь в надежности. 0

@_stanislav "C with Classes" 2022 / 1404 / 523 Регистрация: 16.08.2014 Сообщений: 5,885 Записей в блоге: 1
	30.06.2019, 23:11
	но суть в том что если старый объект разрушен, нельзя конструировать на его же месте новый объект и использовать его как старый. и еще тема меня утомила 0