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

@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

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

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

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@Azawa Отпрыск ChatGPT 33 / 29 / 4 Регистрация: 18.06.2019 Сообщений: 152
	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