Конструирование объектов в Дельфи и С++

Статья Exceptional Safety на блоге The Oracle at Delphi послужила предметом разговора за чашкой чая у нас с мужем, где мы обсуждали насколько же по-разному конструируются объекты в Дельфи и С++.

В С++ порядок конструирования объектов зачастую является источником недопонимания. При вызове конструктора класса сначала конструируется объект базового класса, потом его наследника и так далее. Непонятки начинаются при попытке вызова из конструктора базового класса виртуальной функции.

class CBase 
{
public:
  CBase()
  {
    cout<<"CBase::CBase"<<endl;
    print();
  }
  virtual void print()
  {
    cout<<"print CBase::print"<<endl;
  }
};

class CDerived : public CBase
{
public:
  CDerived()
  {
    cout<<"CDerived::CDerived"<<endl;
  }
  virtual void print()
  {
    cout<<"print CDerived::print"<<endl;
  }
};

int main()
{
  cout<<"Creating CDerived"<<endl;
  CDerived d;
}

Вывод получается такой.

Creating CDerived
CBase::CBase
print CBase::print
CDerived::CDerived

Поскольку vtable CDerived еще не заполнена на момент вызова функции print, будет вызвана функция CBase::print. В Дельфи таблица виртуальных функций, VMT, заполняется перед началом отработки конструктора и таких проблем не возникает.

type
  TBase = class
  protected
    procedure Print; virtual;
  public
    constructor Create;
  end;

  TDerived = class(TBase)
  protected
    procedure Print; override;
  public
    constructor Create;
  end;

{ TBase }

constructor TBase.Create;
begin
  inherited Create;
  ShowMessage('TBase.Create');
  Print;
end;

procedure TBase.Print;
begin
  ShowMessage('TBase.Print');
end;

{ TDerived }

constructor TDerived.Create;
begin
  inherited Create;
  ShowMessage('TDerived.Create');
end;

procedure TDerived.Print;
begin
  ShowMessage('TDerived.Print');
end;

При попытке создать экземляр класса TDerived будут выданы следующие соообщения

TBase.Create
TDerived.Print
TDerived.Create

Причем не только VMT заполняется, вообще создается полный экземпляр класса, заполненный нулями.

В Дельфи все не так как в С++ и с порядком вызова конструктора. Вообще конструкторов может быть несколько и называться они могут по-разному. Но вызывает программист конструктор базового класса явно и тогда, когда ему удобно. Если считает, что это не нужно, то может вообще конструктор базового класса не вызывать.

Такие разные подходы ведут к интересным последствиям в случае выброса исключения из конструктора. В С++ выброс исключения в конструкторе часто рекомендуют для индикации ошибки при конструировании объекта, потому что конструктор не возвращает значений, а писать ошибку куда-либо еще неудобно. Но после выбрасывания исключения из конструктора деструктор вызван не будет. И надо как-то подчищать то, что конструктор успел сделать. Существуют разные способы это сделать, все несколько неочевидные.

В Дельфи в такой ситуации идет неявный вызов деструктора. Который уберет то, что было проинициализировано, но не тронет то, до чего дело не дошло. Не тронет он потому, что изначально все ссылки проинициализированы nil'ами, нулями. Те поля, для которых память уже выделена, будут иметь значения, отличные от nil. Для освобождения ресурсов в Дельфи есть деструктор по умолчанию Destroy и метод ему в помощь под названием Free. Destroy никогда не надо вызывать явно, он считается служебным, а Free отрабатывает следующим образом.
if Self <> nil then Self.Destroy;

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

Ссылки по теме:
Thinking in C++, vol.2. 1.Exception Handling, Cleaning up.
[17] Exceptions and error handling, C++ FAQ Lite