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

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

F>>Прямо говорится:
К>

F>>...any direct or indirect call to an unimplemented pure virtual function from a constructor or destructor results in undefined behavior.

К>Прямой вызов виртуальной функции из ктора/дтора — статический. Если функция не определена (неважно, =0 она или нет), то получим не UB, а ошибку линковки.

Я встречал только один способ подавления виртуальности вызова в стандарте и это — явная квалификация 10.3 (12)
Если нет явной квалификации, вызов — виртуальный. А виртуальный вызов чисто виртуальной функции из ctor/dtor — undefined 10.4 (6)

Лазар

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>struct C : B {
ЛБ>  using A::sf;
ЛБ>  using A::vf;
ЛБ>  C() {
ЛБ>    sf();
ЛБ>    vf();
ЛБ>  }
ЛБ>};

A не является непосредственной базой C, так что пример мимо кассы.

Здравствуйте, Лазар Бешкенадзе, Вы писали:
ЛБ>Вот чего требует стандарт:

ЛБ>12.7 (3)
ЛБ>... When a virtual function is called directly or indirectly from a constructor (including
ЛБ>from the mem-initializer for a data-member) or from a destructor, and the object to which
ЛБ>a call applies is the object under construction or destruction, the function called is the
ЛБ>one defined in the constructor or destructor's own class or in one of its bases, ...

ЛБ>Покажи, где тут говорится о каком-либо соответствии.
То, что ты привел — и есть правила для вызова обычной функции, если ты этого не заметил

ЛБ>К тому же приведенный здесь пример

Автор: Лазар Бешкенадзе
Дата: 15.03.06

явно показывал несоответствие.
Он показал лишь то, что используемый тобой компилятор выполняет вызов в соответствии с требованием стандарта, и ничего более.
ЛБ>А тут еще один пример

Автор: Лазар Бешкенадзе
Дата: 15.03.06

.
Этот пример вообще некомпилируем.

ЛБ>Тут так все перевернуто с ног на голову, что мне остается только улыбнуться:
ЛБ>

А у меня есть еще кое-что, кроме улыбок:
предлагаю помедитировать над следующим примером:

#include <iostream>

using namespace std;

struct B
{
   virtual ~B() {}
   virtual void vf() { cout << "B::vf\n"; }
   virtual void vg() { cout << "B::vg\n"; }
};

struct D1 : public virtual B
{
   virtual void vf() { cout << "D1::vf\n"; }
   ~D1()
   {
      cout << "~D1\n";
      static_cast<B*>(this)->vf();
      static_cast<B*>(this)->vg();
   }
};

struct D2 : public virtual B
{
   virtual void vg() { cout << "D2::vg\n"; }
   ~D2() 
   { 
      cout << "~D2\n"; 
      static_cast<B*>(this)->vf();
      static_cast<B*>(this)->vg();
   }
};

struct D3 : public D2, public D1
{
};

int main()
{
   D3 d;
   B* pb = &d;
   pb->vf();
   pb->vg();
 
  return 0;
}

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

B>Здравствуйте, Лазар Бешкенадзе, Вы писали:
ЛБ>>Вот чего требует стандарт:

ЛБ>>12.7 (3)
ЛБ>>... When a virtual function is called directly or indirectly from a constructor (including
ЛБ>>from the mem-initializer for a data-member) or from a destructor, and the object to which
ЛБ>>a call applies is the object under construction or destruction, the function called is the
ЛБ>>one defined in the constructor or destructor's own class or in one of its bases, ...

ЛБ>>Покажи, где тут говорится о каком-либо соответствии.
B>То, что ты привел — и есть правила для вызова обычной функции, если ты этого не заметил
ЛБ>>К тому же приведенный здесь пример

Автор: Лазар Бешкенадзе
Дата: 15.03.06

явно показывал несоответствие.
B>Он показал лишь то, что используемый тобой компилятор выполняет вызов в соответствии с требованием стандарта, и ничего более.
ЛБ>>А тут еще один пример

Автор: Лазар Бешкенадзе
Дата: 15.03.06

.
B>Этот пример вообще некомпилируем.


Если ты имеешь ввиду void main(), то эта моя ошибка есть и в первом примере.
Я приношу глубочайшие извинения, переделывал ее из другой функции и оплошал.
Замени, пожалуйста, void на int — все скомпилируется.

ЛБ>>Тут так все перевернуто с ног на голову, что мне остается только улыбнуться:
ЛБ>>

B>А у меня есть еще кое-что, кроме улыбок:
B>предлагаю помедитировать над следующим примером

Автор: Bell
Дата: 15.03.06

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

12.7 (3)
... but not a function, overriding it in a class derived from the constructor
or destructor's class, or overriding it in one of the other base classes
of the most derived object.

Я, пожалуй, остановлюсь на этом, потому как ты говоришь на другом языке. Для
тебя вызов является виртуальным, если он идет через vtbl, а в стандарте просто
нет понятия vtbl. Правила для виртуальных функций описываются так, как в
приведенном параграфе.

Лазар

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

К>Здравствуйте, Лазар Бешкенадзе, Вы писали:

К>

ЛБ>>struct C : B {
ЛБ>>  using A::sf;
ЛБ>>  using A::vf;
ЛБ>>  C() {
ЛБ>>    sf();
ЛБ>>    vf();
ЛБ>>  }
ЛБ>>};
К>

К>A не является непосредственной базой C, так что пример мимо кассы.

Это — шутка в продолжение темы непосредственности?


Лазар

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>
ЛБ>Если ты имеешь ввиду void main(), то эта моя ошибка есть и в первом примере.
Нет, я имею ввиду использование using declaration:

7.3.3/14
...
The base class members mentioned by a using-declaration shall be visible 
in the scope of at least one of the direct base classes of the class 
where the using-declaration is specified.
...

Т.е. нельзя в C писать using A::sf, поскольку она скрыта в непосредственном базовом классе (т.е. в B).

ЛБ>>>Тут так все перевернуто с ног на голову, что мне остается только улыбнуться:
ЛБ>>>

B>>А у меня есть еще кое-что, кроме улыбок:
B>>предлагаю помедитировать над следующим примером

Автор: Bell
Дата: 15.03.06

ЛБ>Тут нечего медитировать. Специально для тебя продолжение параграфа из стандарта.
ЛБ>Опять же приношу извинения, что первый раз поленился привести полностью.

ЛБ>12.7 (3)
ЛБ>... but not a function, overriding it in a class derived from the constructor
ЛБ>or destructor's class, or overriding it in one of the other base classes
ЛБ>of the most derived object.

Я читал этот пункт стандарта, но все равно спасибо.

ЛБ>Я, пожалуй, остановлюсь на этом, потому как ты говоришь на другом языке.
Да, похоже, что мы говорим на разных языках.

ЛБ>Для тебя вызов является виртуальным, если он идет через vtbl, а в стандарте просто
ЛБ>нет понятия vtbl.
Я такого не говорил — наоборот, я говорил, что вызов виртуальной функции из конструктора может быть реализован через таблицу виртуальных функций (если виртуальный функции реализованы через таблицу).

ЛБ>Правила для виртуальных функций описываются так, как в приведенном параграфе.
С этим трудно спорить, однако эти правила немного отличаются от того, с чего начал ты:

На самом деле работают, более того, работают именно как
виртуальные, просто вызывается последний override на момент
создания объекта класса исполняемого конструктора/деструктора

Поясню свой пример, поскольку, как мне кажется, его смысл от тебя ускользнул:
в деструкторе D1 вызов vg приводит к вызову B::vg, хотя подобъект D2 еще жив, и таким образом последний override — это D2::vg.
Это поведение, естественно, соответствует правилам из 12.7/3, но никак не твоему "правилу последнего override — а".

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

Б>>На самом деле работают, более того, работают именно как виртуальные

ЛБ>>Фразу, что я комментировал можно понимать как отключение виртуального механизма вызова и переход на статический при вызове виртуального метода из конструктора/деструктора.

B>Что же касается моего утверждения о механизмах вызова, то тут я погорячился.
B>Стандарт требует, чтобы вызов (как приямой, так и опосредованный) виртуальной функции в конструкторе/деструкторе соответствовал прямому вызову "обычной" функции.

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

class CBase {
protected:
  virtual void Start() = 0;
  virtual void Finish() = 0;

public:
  void Run() {
    Start();
    // ...
    Finish();
  }
};

class CDerived : public CBase {
protected:
  virtual void Start() { /* ... */ }
  virtual void Finish() { /* ... */ }
};

Эта функциональность будет прекрасно работать и при вызове метода 'Run()' из конструктора/деструктора класса-наследника с той только оговоркой, что виртуальные вызовы буду выполняться так, как будто динамический типом объекта является именно тот тип, чей конструктор/деструктор непосредственно работает в данный момент. Тем не менее вызовы виртуальных методов будут вести себя совершенно "виртуально" (с учетом предыдущей оговорки). Виртуальность никак не отрицается тем фактом, что опосредованный вызов виртуальных функций соответствует по своему эффекту их прямому вызову из конструктора/деструктора класса-наследника.

Изначальное утверждение Лазара было, по моему мнению, совершенно верным. Виртуальность в С++ работает из конструткоров/деструкторов "до уровня" непосредственно конструируемого/деструктируемого объекта. Именно этого требует спецификация языка. А как это реализовано -"прямыми" вызовами или "непрямыми" — это уже детали реализации. Спецификация не оперирует такими понятиями.

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

E>Как видно из этого листинга, ни о каком виртуальном вызове (в случае с Foo), тут речи и не идет. Адрес берется не из vtable, а уже известен на момент компиляции. Поэтому фраза "работают именно как виртуальные", как справедливо заметил Bell, совершенно несправедлива.

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

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

CClass c;
c.some_virtual_method();
// Вызов виртуального метода. Практически любой компилятор странслирует в прямой вызов
// c.CClass::some_virtual_method(); 

CClass* pc = &c;
pc->some_virtual_method();
// "Умный" компилятор сообразит, что динамический тип '*pc' есть 'CClass' и генерирует прямой вызов
// pc->CClass::some_virtual_method()

Но на уровне языка вызовы от этого не перестают быть виртуальными. Остальное — детали реализации.

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

АТ>Я не совсем понимаю почему это утверждение используется как аргумент при в пользу некоего "отсутствия виртуальности".
...
АТ>Эта функциональность будет прекрасно работать и при вызове метода 'Run()' из конструктора/деструктора класса-наследника с той только оговоркой, что виртуальные вызовы буду выполняться так, как будто динамический типом объекта является именно тот тип, чей конструктор/деструктор непосредственно работает в данный момент.

Никто не доказывает "отсутсвие виртуальности". Более того, в одном из своих постов

Автор: Bell
Дата: 15.03.06

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

...
На самом деле работают, более того, работают именно как виртуальные, просто вызывается последний override на момент создания объекта класса исполняемого конструктора/деструктора.

Пример, который я приводил, ИМХО достаточно красноречиво говорит о том, что это объяснение не верно.

Ну а твое объяснение (с учетом немаловожной, ИМХО, "оговорки") объясняет все правильно, впрочем как и обяснение "вызов виртуальной функции в конструкторе/деструкторе осуществляется по тем же правилам, что и прямой вызов "обычной" функции".