Вызов виртуального метода в конструкторе базового класса

(Этот ответ относится к C# и Java. Я считаю, что C++ работает по-разному в этом вопросе.)

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

Я бы по возможности постарался этого избежать, но не загибая конструкцию чрезвычайно. (Например, опция «инициализировать позже» запрещает неизменяемость.) Если вы делать используете виртуальный метод в конструкторе, строго задокументируйте его очень. Пока все участники осведомлены о том, что делают, это не должно вызывать у тоже много проблем. Я бы попытался ограничить видимость, как вы это сделали в своем первом примере.

Обновлено: Здесь важно то, что существует разница между C# и Java в порядке инициализации. Если у вас есть такой класс, как:

public class Child : Parent
{
    private int foo = 10;

    protected override void ShowFoo()
    {
        Console.WriteLine(foo);
    }
}

где конструктор Parent вызывает ShowFoo, в C# он будет отображать 10. Эквивалентная программа в Java отобразит 0.

В C++ вызов виртуального метода в конструкторе базового класса просто вызовет метод, как если бы производный класс еще не существует (потому что его нет). Таким образом, это означает, что вызов разрешается во время компиляции для любого метода, который он должен вызывать в базовом классе (или классах, от которых он является производным).

Протестировано с помощью GCC, оно позволяет вызывать чистую виртуальную функцию из конструктора, но выдает предупреждение и приводит к ошибке времени ссылки. Похоже, что это поведение не определено стандартом:

"Функции-члены могут быть вызваны из конструктора (или деструктора) абстрактного класса; эффект от виртуального вызова (class.virtual) чистой виртуальной функции прямо или косвенно для объекта, создаваемого (или уничтожаемого) из такого конструктора ( или деструктор) не определено. "

В C++ виртуальные методы маршрутизируются через vtable для создаваемого класса. Таким образом, в вашем примере это сгенерирует исключение чистого виртуального метода, поскольку пока создается BaseObject, просто нет метода LoadStateCore для вызова.

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

По этой причине вы просто не можете сделать это в C++ ...

Для C++ этот случай рассматривается в параграфе 3 раздела 12.7 Стандарта.

Подводя итог, это законно. Он разрешит правильную функцию для типа запускаемого конструктора. Следовательно, адаптируя свой пример к синтаксису C++, вы должны будете вызвать BaseObject::LoadState(). Вы не можете добраться до ChildObject::LoadState(), и попытка сделать это, указав класс, а также функцию, приводит к неопределенному поведению.

Конструкторы абстрактных классов рассматриваются в разделе 10.4, параграф 6. Вкратце, они могут вызывать функции-члены, но вызов чистой виртуальной функции в конструкторе является неопределенным поведением. Не делай этого.

Обычно эти проблемы можно обойти, используя более жадный базовый конструктор. В вашем примере вы передаете XElement в LoadState. Если вы разрешаете напрямую устанавливать состояние в базовом конструкторе, ваш дочерний класс может анализировать XElement до вызова вашего конструктора.

public abstract class BaseObject {
   public BaseObject(int state1, string state2, /* blah, blah */) {
      this.State1 = state1;
      this.State2 = state2;
      /* blah, blah */
   }
}

public class ChildObject : BaseObject {
   public ChildObject(XElement definition) : 
      base(int.Parse(definition["state1"]), definition["state2"], /* blah, blah */) {
   }
}

Если дочернему классу нужно немного поработать, его можно передать статическому методу.

Для C++ базовый конструктор вызывается перед производным конструктором, что означает, что виртуальная таблица (которая содержит адреса переопределенных виртуальных функций производного класса) еще не существует. По этой причине это считается ОЧЕНЬ опасным делом (особенно, если функции являются чисто виртуальными в базовом классе ... это вызовет чисто виртуальное исключение).

Есть два способа обойти это:

1. Сделайте двухэтапный процесс построения + инициализации
2. Переместите виртуальные функции во внутренний класс, которым вы можете более внимательно управлять (можно использовать вышеупомянутый подход, см. Пример для подробностей)

Пример (1):

class base
{
public:
    base()
    {
      // only initialize base's members
    }

    virtual ~base()
    {
      // only release base's members
    }

    virtual bool initialize(/* whatever goes here */) = 0;
};

class derived : public base
{
public:
    derived ()
    {
      // only initialize derived 's members
    }

    virtual ~derived ()
    {
      // only release derived 's members
    }

    virtual bool initialize(/* whatever goes here */)
    {
      // do your further initialization here
      // return success/failure
    }
};

Пример (2):

class accessible
{
private:
    class accessible_impl
    {
    protected:
        accessible_impl()
        {
          // only initialize accessible_impl's members
        }

    public:
        static accessible_impl* create_impl(/* params for this factory func */);

        virtual ~accessible_impl()
        {
          // only release accessible_impl's members
        }

        virtual bool initialize(/* whatever goes here */) = 0;
    };

    accessible_impl* m_impl;

public:
    accessible()
    {
        m_impl = accessible_impl::create_impl(/* params to determine the exact type needed */);

        if (m_impl)
        {
            m_impl->initialize(/* ... */);  // add any initialization checking you need
        }
    }

    virtual ~accessible()
    {
        if (m_impl)
        {
            delete m_impl;
        }
    }

    /* Other functionality of accessible, which may or may not use the impl class */
};

Подход (2) использует шаблон Factory для обеспечения соответствующей реализации класса accessible (который будет предоставлять тот же интерфейс, что и ваш класс base). Одним из основных преимуществ здесь является то, что вы получаете инициализацию во время создания accessible, которая может безопасно использовать виртуальные члены accessible_impl.

Если у вас есть класс, показанный в вашем сообщении, который принимает XElement в конструкторе, то единственное место, откуда мог появиться XElement, - это производный класс. Так почему бы просто не загрузить состояние в производном классе, в котором уже есть XElement.

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

т.е.

public class BaseClass
{
    public BaseClass(XElement defintion)
    {
        // base class loads state here
    }
}

public class DerivedClass : BaseClass
{
    public DerivedClass (XElement defintion)
        : base(definition)
    {
        // derived class loads state here
    }
}

Тогда ваш код действительно прост, и у вас нет проблем с вызовом виртуального метода.

В C++ совершенно безопасно вызывать виртуальные функции из базового класса - пока они нечистый - с некоторыми ограничениями. Однако делать этого не стоит. Лучше инициализировать объекты, используя невиртуальные функции, которые явно помечены как такие функции инициализации с помощью комментариев и соответствующего имени (например, initialize). Если он даже объявлен как чисто виртуальный в вызывающем его классе, поведение не определено.

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

В C# и Java это не проблема, потому что не существует такой вещи, как инициализация по умолчанию, которая выполняется непосредственно перед входом в тело конструктора. В C# единственное, что делается за пределами тела, - это вызов конструкторов базового класса или родственных ему конструкторов. Однако в C++ инициализация, выполненная для членов производных классов переопределителем этой функции, будет отменена при построении этих членов при обработке списка инициализаторов конструктора непосредственно перед входом в тело конструктора производного класса.

Редактировать: Из-за комментария, я думаю, необходимо немного пояснения. Вот (надуманный) пример, давайте предположим, что будет разрешено вызывать виртуальные объекты, и этот вызов приведет к активации последнего переопределителя:

struct base {
    base() { init(); }
    virtual void init() = 0;
};

struct derived : base {
    derived() {
        // we would expect str to be "called it", but actually the
        // default constructor of it initialized it to an empty string
    }
    virtual void init() {
        // note, str not yet constructed, but we can't know this, because
        // we could have called from derived's constructors body too
        str = "called it";
    }
private:
    string str;
};

Эта проблема действительно может быть решена путем изменения стандарта C++ и его разрешения - корректировки определения конструкторов, времени жизни объекта и прочего. Потребуются правила, определяющие, что str = ...; означает для еще не созданного объекта. И обратите внимание, как эффект от этого зависит от того, кто позвонил в init. То, что мы получаем, не оправдывает тех проблем, которые нам предстоит решать. Таким образом, C++ просто запрещает динамическую отправку во время создания объекта.

Для C++ прочтите соответствующую статью Скотта Мейера:

Никогда не вызывайте виртуальные функции во время строительства или разрушения

ps: обратите внимание на это исключение в статье:

The problem would almost certainly become apparent before runtime, because the logTransaction function is pure virtual in Transaction. Unless it had been defined (unlikely, butpossible) the program wouldn't link: the linker would be unable to find the necessary implementation of Transaction::logTransaction.