Порядок вызова деструкторов объектов класса всегда обратен вызову их конструкторов?
Т.е допустим есть класс
class A
{
B b;
D d;
}

то порядок вызова деструкторов всегда будет:
~A()
~D()
~B()

?

Здравствуйте, Аноним, Вы писали:

А>Порядок вызова деструкторов объектов класса всегда обратен вызову их конструкторов?
Да.

Здравствуйте, Аноним, Вы писали:

А>Порядок вызова деструкторов объектов класса всегда обратен вызову их конструкторов?
Да.

А>Т.е допустим есть класс
А>class A
А>{
А> B b;
А> D d;
А>}

А>то порядок вызова деструкторов всегда будет:
А>~A()
А>~D()
А>~B()

А>?
Нет, порядок вызова деструкторов будет: ~D(), ~B(), ~A().

Здравствуйте, Аноним, Вы писали:

А>Нет, порядок вызова деструкторов будет: ~D(), ~B(), ~A().
Туплю, все правильно у автора вопроса было )

А>то порядок вызова деструкторов всегда будет:
А>~A()
А>~D()
А>~B()

Да. Только лучше не закладываться на это особо. Ну то есть не наворачивать что то шибко хитрое, завязанное на порядок вызова деструкторов. имхо.

Здравствуйте, Аноним, Вы писали:

А>Порядок вызова деструкторов объектов класса всегда обратен вызову их конструкторов?
А>Т.е допустим есть класс
А>class A
А>{
А> B b;
А> D d;
А>}

А>то порядок вызова деструкторов всегда будет:
А>~A()
А>~D()
А>~B()

А>?

да, вызов деструкторов обратно вызову конструкторов -- LIFO
порядок конструкторов: сначала члены, потом сам конструктор класса.
члены в порядке пеерчисления в классе/структуре

Здравствуйте, Sashaka, Вы писали:

А>>то порядок вызова деструкторов всегда будет:
А>>~A()
А>>~D()
А>>~B()

S>Да. Только лучше не закладываться на это особо. Ну то есть не наворачивать что то шибко хитрое, завязанное на порядок вызова деструкторов. имхо.

а на что надеятся если даже не на это???

S>Да. Только лучше не закладываться на это особо. Ну то есть не наворачивать что то шибко хитрое, завязанное на порядок вызова деструкторов. имхо.

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

А вот закладываться в деструкторе B::~B на то, разрушен ли объект D, находящийся рядом с B внутри объекта А — и впрямь довольно-таки глупо.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>А вот закладываться в деструкторе B::~B на то, разрушен ли объект D, находящийся рядом с B внутри объекта А — и впрямь довольно-таки глупо.

Я бы ни в каких методах D на существование "объектов рядом" закладываться не советовал бы

MSS>>А вот закладываться в деструкторе B::~B на то, разрушен ли объект D, находящийся рядом с B внутри объекта А — и впрямь довольно-таки глупо.

E>Я бы ни в каких методах D на существование "объектов рядом" закладываться не советовал бы

И я

Здравствуйте, ilnar, Вы писали:

I>Здравствуйте, Sashaka, Вы писали:

А>>>то порядок вызова деструкторов всегда будет:
А>>>~A()
А>>>~D()
А>>>~B()

S>>Да. Только лучше не закладываться на это особо. Ну то есть не наворачивать что то шибко хитрое, завязанное на порядок вызова деструкторов. имхо.

I>а на что надеятся если даже не на это???

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

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

ну то есть если есть например class C { T a; T b; T d; } то С вполне может рассчитывать в своем деструкторе что a,b,d еще не разрушены, а вот d или a в своем уже НЕ ДОЛЖНЫ рассчитывать на b...

S>ну то есть если есть например class C { T a; T b; T d; } то С вполне может рассчитывать в своем деструкторе что a,b,d еще не разрушены, а вот d или a в своем уже НЕ ДОЛЖНЫ рассчитывать на b...

А откуда вообще "d" или "a" могут знать о "b" ???

Здравствуйте, K13, Вы писали:

K13>А откуда вообще "d" или "a" могут знать о "b" ???
Например их там можно регистрировать...
А можно кастить что-нибудь куда-нибудь, а можно...

template<typename T> midian( T a, T b, T c ); // возвращает самое "среднее" из трёх чисел
class SubObject {
public:
    int GetValue() const { return midian( value, this[-1].value, this[+1].value ); }
private:
    int value;
}

Здравствуйте, Аноним.

Стоит немного дополнить.
Порядок конструирования объекта: базовые классы (в порядке наследования), члены (в порядке объявления), сам класс, таблицы виртуальных функций.
Вызов деструкоров — в обратном порядке.

Здравствуйте, _Paul, Вы писали:

_P>Порядок конструирования объекта: базовые классы (в порядке наследования)
Это в случае, если нет виртуальных баз. Иначе ситуация немного запутывается. Например:

class A {};
class B : public virual A {};
class C: public B, public virtual A {};

Конструкторы позовотся в порядке: A, B, C, а не B, A, C...

_P> таблицы виртуальных функций.
Таки про таблицы виртуальных функций в стандарте нет не слова...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>А вот закладываться в деструкторе B::~B на то, разрушен ли объект D, находящийся рядом с B внутри объекта А — и впрямь довольно-таки глупо.

E>Я бы ни в каких методах D на существование "объектов рядом" закладываться не советовал бы

Как я понимаю имеются в виду конструкция типа:

class D
{
B &m_bclass;
public:
D(B &p_b) : m_bclass(p_b) {}
~D() {p_b.D_cleanup();}
...
}

Т.е. если один объект следит за/управляет другим...

Здравствуйте, Erop, Вы писали:

E>Таки про таблицы виртуальных функций в стандарте нет не слова...

а вот интересно могла бы быть реализация инициализации таблицы вирутальных функций такой:

в конструкторе базового класса создается таблица. далее (равно как и для всех прозводных классов) устанавливаются указатели на виртуальные функции "текущего" класса, т.е.

Base::Base -> CreateTable -> Table[func] = Base::func
Derived::Derived -> Table[func] = Derived::func
Derived1::Derived1 -> Table[func] = Derived1::func

все очень примитивно и просто, и вроде бы соответствует стандарту?