Деструктор

@clicksel · Регистрация: 09.08.2010

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

Изучаю С++ по самоучителю щас прохожу конструкторы и деструкторы вознила такая проблема

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#include<iostream>
#include<conio.h>
using namespace std;
class MyClass{
    int val;
public:
    MyClass(int i){
        val=i;
        cout<<"Vnutri konstruktora.\n";
    }
 
    ~MyClass()
    {cout <<"Razrushenie Obiekta.\n";}
 
    int getval(){return val;}
};
void display (MyClass ob)
{
    cout<<ob.getval()<<endl;
}
int main()
{
    MyClass a(10);
    cout<<"Do vizova funkcii display().\n";
    display(a);
    cout<<"Posle vipolnenia funkcii display().\n";
 
 
    getch();
    return 0;
    
}

при выполнении этого кода в книге написанно что программа на экран должна вывести следующий текст:
Vnutri konstruktora.
Do vizova funkcii display().
10
Razrushenie Obiekta.
Posle vipolnenia funkcii display().
Razrushenie Obiekta.

У меня же выдает только :
Vnutri konstruktora.
Do vizova funkcii display().
10
Razrushenie Obiekta.
Posle vipolnenia funkcii display().

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

P.S. извините если тему не в том отделе создал наверно надо было в разделе для начинающих... просто компилирую в visual C++

@CheshireCat · 11.08.2010, 15:44

Нет. Стандарт (3.6.2) как раз жестко определяет, что в пределах одной единицы трансляции порядок конструирования и разрушения глобальных объектов четко определен. Равно как и порядок их разрушения - он строго обратен порядку конструирования. А вот если глобальные объекты расположены в разных единицах трансляции - таки да, порядок их конструирования будет как Б.Г. на душу положит.
Что же касается глобального объекта cout, то он конструируется один раз при первом включении <iostream> - и этот хитрый финт тоже описан у Элджера. Ну и разрушается в соответствующий момент.
Тот факт, что за конструирование и разрушение глобальных объектов отвечает стартовый/финализирующий код приложения - сути процесса не меняет.

Evg · 11.08.2010, 16:22

Про порядок внутри одного модуля учтём.

Про cout и то, что он конструируется один раз я как-то не догнал. Этот объект в каждом модуле получается свой чтоли (т.е. дублируется)?

Но вопрос мой всё равно был не про это. А про порядок между вызовом конструкторов в программе и библиотеке. Тогда попробоую на примере и без всяких cout'ов, чтобы он глаза не мозололил

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* Файл mod.cc - грубо говоря, наша программа */
 
#include <stdio.h>
 
class A
{
 public:
  A() { printf ("constr mod\n"); }
  ~A() { printf ("destr mod\n"); }
};
 
A a;
 
extern void
func (void);
 
int main (void)
{
  /* это нужно, чтобы библиотека подлинковалась, а не выкинулась как неиспользуемая */
  func();
}

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/* Файл lib.cc - грубо говоря, библиотека */
 
#include <stdio.h>
 
class B
{
 public:
  B() { printf ("constr lib\n"); }
  ~B() { printf ("destr lib\n"); }
};
 
B b;
 
void
func (void)
{
}

Code
1
2
3
4
5
6
7
8
9
$ g++ mod.c -c
$ g++ lib.c -c
$ ar cr liba.a lib.o
$ g++ mod.o -L. -la
$ ./a.out
constr lib
constr mod
destr mod
destr lib

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

В исходниках gcc видно, что спецально предпринимаются попытки вызова именно в этом порядке (в исходниках файл crtstuff.c процедуры __do_global_ctors_aux и __do_global_dtors_aux)

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

В общем, по ходу я что-то тут нагнал, щас надо разобраться, в чём же именно нагнал

@CheshireCat · 11.08.2010, 16:41

Я повторил твой эксперимент, и все получилось не так очевидно уже.... Если имена файлов mod.cc и lib.cc, то получается:

constr lib
constr mod
destr mod
destr lib

А вот если изменить имена на amod.cc и lib.cc, то получится уже вот что:

constr mod
constr lib
destr lib
destr mod

Компилятор GCC 4.4.0. Я уже сталкивался с тем, что компилятор любит обрабатывать модули в алфавитном порядке их имен, поэтому сразу же провел именно такой эксперимент. И его результат вполне себе показателен - как-либо полагаться на порядок инициализации "библиотечных" и "программных" объектов нельзя, если этот порядок не гарантирован жестко - то ли он гарантирован в документации на библиотеку, то ли благодаря умелым рукам программиста. Что вполне соответствует букве Стандарта :-)

Evg · 11.08.2010, 17:16

Стоп. Запускать надо именно так, как я показывал. Один файл идёт как просто объектный файл в линковку, а другой в виде библиотеки (собственно почему я уже несколько постов напираю именно на понятие "библиотека").

Про гарантированность порядка - выходит действительно это свойство gcc. Но такую хрень мы наблюдали на Sun'овском компиляторе, на Intel'овском компиляторе для Itanium'а и непонятно каким компилятором для MIPS'а. Т.е. скорее всего и правда это свойство стандарт не гарантирует, а потому закладываться на него некорректно с точки зрения переносимости. Но gnu'тый софт может смело закладываться, поскольку большинство его расчитано именно на gcc

Новые блоги и статьи Все статьи Все блоги /
Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .	ИИ не может найти нужный язык в списке 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, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .

@CheshireCat 2924 / 1274 / 114 Регистрация: 27.05.2008 Сообщений: 3,465
	11.08.2010, 15:44
	Нет. Стандарт (3.6.2) как раз жестко определяет, что в пределах одной единицы трансляции порядок конструирования и разрушения глобальных объектов четко определен. Равно как и порядок их разрушения - он строго обратен порядку конструирования. А вот если глобальные объекты расположены в разных единицах трансляции - таки да, порядок их конструирования будет как Б.Г. на душу положит. Что же касается глобального объекта cout, то он конструируется один раз при первом включении <iostream> - и этот хитрый финт тоже описан у Элджера. Ну и разрушается в соответствующий момент. Тот факт, что за конструирование и разрушение глобальных объектов отвечает стартовый/финализирующий код приложения - сути процесса не меняет. 2

@CheshireCat 2924 / 1274 / 114 Регистрация: 27.05.2008 Сообщений: 3,465
	11.08.2010, 16:41
	Я повторил твой эксперимент, и все получилось не так очевидно уже.... Если имена файлов mod.cc и lib.cc, то получается: constr lib constr mod destr mod destr lib А вот если изменить имена на amod.cc и lib.cc, то получится уже вот что: constr mod constr lib destr lib destr mod Компилятор GCC 4.4.0. Я уже сталкивался с тем, что компилятор любит обрабатывать модули в алфавитном порядке их имен, поэтому сразу же провел именно такой эксперимент. И его результат вполне себе показателен - как-либо полагаться на порядок инициализации "библиотечных" и "программных" объектов нельзя, если этот порядок не гарантирован жестко - то ли он гарантирован в документации на библиотеку, то ли благодаря умелым рукам программиста. Что вполне соответствует букве Стандарта :-) 0

Evg 21285 / 8310 / 637 Регистрация: 30.03.2009 Сообщений: 22,671 Записей в блоге: 30
	11.08.2010, 17:16
	Стоп. Запускать надо именно так, как я показывал. Один файл идёт как просто объектный файл в линковку, а другой в виде библиотеки (собственно почему я уже несколько постов напираю именно на понятие "библиотека"). Про гарантированность порядка - выходит действительно это свойство gcc. Но такую хрень мы наблюдали на Sun'овском компиляторе, на Intel'овском компиляторе для Itanium'а и непонятно каким компилятором для MIPS'а. Т.е. скорее всего и правда это свойство стандарт не гарантирует, а потому закладываться на него некорректно с точки зрения переносимости. Но gnu'тый софт может смело закладываться, поскольку большинство его расчитано именно на gcc 0