Коротко. О конструкторах

Депрессия - "частично" побеждена.

Много ошибок найдено.

В частности - СПАСИБО NameRec'у - http://programmingmindstream.blogspot.ru/2014/09/blog-post_23.html?showComment=1411514362019#c1699121675114974966

Нагрузочные тесты на основе GUI-тестов - написаны.

Эмулируют работу реальных пользователей в распределённой системе.

С нескольких машин.

Примерно так:

1. Случайным образом открывают документ (из заранее определённого списка).
2. Вводят "два три слова".
3. Сохраняют.
4. Закрывают документ.

Вот кстати код теста:

USES
 QuickTestsUtils.script
;

Тест TK565491886

 ARRAY VAR "Список документов"
 [ Конституция ГК НК ТК ТНВЭД ОКОФ ОКОНХ ] >>> "Список документов"         

 BOOLEAN VAR Вечность
 ДА >>> Вечность 
 ПОКА Вечность (
          INTEGER VAR "Случайный документ"
          ( "Список документов" array:Count Random "Список документов" [i] ) >>> "Случайный документ" 
     Параметры: ( "Документ из базы {("Случайный документ")}" )
     Выполнить ( 
  "Набить текст {('Вносим изменения в текст и сохраняем документ!!!')}"
  "Нажать Enter" // - чтобы отделить параграфы документа, иначе параграфы могут быть "слишком длинными" для восприятия
  "Сохранить документ"
  "Обработать сообщения" // - чтобы приложение перерисовывалось
   )
        )
;

TK565491886

Молотят уже третий день.

Намолотили порядка 9 Гб.

Оставил на выходные. Посмотрим, что будет.

По результатам - напишу глубокий анализ.

Одно пока могу сказать - даже если функция ReadFile "считала что-то" и вернула ReadSize = SizeToRead - "это не повод успокаиваться". Даже если "оно считало" то "что нужно". И даже если считанные результаты совпадают с данными из файла.

Надо проверять Result функции ReadFile, который BOOL. Ну и GetLastError.

Например оно может вернуть LockViolation или NetworkBusy.

Банально. Да.

Но я про это "ещё потом напишу".

А теперь я хотел написать про конструкторы.

По мотивам:

Ссылка. Получение ресурса есть инициализация (RAII). И "немного от себя"
Коротко. И ещё о фабриках
Коротко. Ещё немного "рассуждений о RAII"
Коротко. Ещё о фабриках
Коротко. О фабриках
Собственная реализация IUnknown и подсчёт ссылок. И примеси
Почему всегда нужно использовать FreeAndNil вместо Free - это надо перечитать особенно и внимательно потому, что моя мысль проистекает из "такой же парадигмы". Виртуальность. И классы-потомки.
Коротко. "Нелюбителям" FreeAndNil
Сегодня получил неожиданное пятикратное подтверждение тому, почему надо писать FreeAndNil, а не Free
Правило 9: Никогда не вызывайте виртуальные функции в конструкторе или деструкторе
Виртуальные функции в конструкторе и деструкторе

У gunsmoker'а написано про деструкторы, а я хочу написать про конструкторы.

Теперь собственно то, что я хотел написать о конструкторах:

Обычно конструкторы пишутся так:

type
 TObject1 = class
 end;//TObject1

 TObject2 = class
 end;//TObject2

 TA = class
  private
   f_SomeObject1 : TObject1;
  public
   constructor Create;
 end;//TA

 TB = class(TA)
  private
   f_SomeObject2 : TObject2;
  public
   constructor Create;
 end;//TB

...

constructor TA.Create;
begin
 inherited Create;
 f_SomeObject1 := TObject1.Create;
end;

...

constructor TB.Create;
begin
 inherited Create;
 f_SomeObject2 := TObject2.Create;
end;

Этот "стиль" нам "завещал ещё Борланд"... Почивший в бозе.

И все мы к нему "привыкли".

Что в нём не так?

Вообще говоря "правильнее" написать так:

type
 TObject1 = class
 end;//TObject1

 TObject2 = class
 end;//TObject2

 TA = class
  private
   f_SomeObject1 : TObject1;
  public
   constructor Create;
 end;//TA

 TB = class(TA)
  private
   f_SomeObject2 : TObject2;
  public
   constructor Create;
 end;//TB

...

constructor TA.Create;
begin
 f_SomeObject1 := TObject1.Create;
 inherited Create;
end;

...

constructor TB.Create;
begin
 f_SomeObject2 := TObject2.Create;
 inherited Create;
end;

Что мы тут сделали?

Мы ПОМЕНЯЛИ местами инициализацию "агрегированных объектов" и "вызов унаследованных конструкторов".

Это - ВАЖНО.

Почему?

Ключевое слово - виртуальность.

Что я имею в виду?

Давайте напишем "пока" так:

type
 TObject1 = class
  public
   SomeField : SomeDataType;
 end;//TObject1

 TObject2 = class
  public
   SomeField : SomeDataType;
 end;//TObject2

 TA = class
  private
   f_SomeObject1 : TObject1;
   f_SomeData : Integer;
  protected
   function CalcSomeData: Integer; virtual;
  public
   constructor Create;
 end;//TA

 TB = class(TA)
  private
   f_SomeObject2 : TObject2;
  protected
   function CalcSomeData: Integer; override;
  public
   constructor Create;
 end;//TB

...

constructor TA.Create;
begin
 inherited Create;
 f_SomeObject1 := TObject1.Create;
 f_SomeData := CalcSomeData;
end;

function TA.CalcSomeData: Integer;
begin
 Result := SomeAlgorythm1(f_SomeObject1.SomeField);
 // - тут всё хорошо
end;

...

constructor TB.Create;
begin
 inherited Create;
 f_SomeObject2 := TObject2.Create;
end;

function TB.CalcSomeData: Integer;
begin
 Result := SomeAlgorythm2(f_SomeObject2.SomeField);
 // - тут получаем AV, потому, что при вызове CalcSomeData из конструктора TA.Create - поле f_SomeObject2  - не инициализировано
end;

Как быть?

Теперь напишем так:

type
 TObject1 = class
  public
   SomeField : SomeDataType;
 end;//TObject1

 TObject2 = class
  public
   SomeField : SomeDataType;
 end;//TObject2

 TA = class
  private
   f_SomeObject1 : TObject1;
   f_SomeData : Integer;
  protected
   function CalcSomeData: Integer; virtual;
  public
   constructor Create;
 end;//TA

 TB = class(TA)
  private
   f_SomeObject2 : TObject2;
  protected
   function CalcSomeData: Integer; override;
  public
   constructor Create;
 end;//TB

...

constructor TA.Create;
begin
 f_SomeObject1 := TObject1.Create;
 inherited Create;
 f_SomeData := CalcSomeData;
end;

function TA.CalcSomeData: Integer;
begin
 Result := SomeAlgorythm1(f_SomeObject1.SomeField);
 // - тут всё хорошо
end;

...

constructor TB.Create;
begin
 f_SomeObject2 := TObject2.Create;
 inherited Create;
end;

function TB.CalcSomeData: Integer;
begin
 Result := SomeAlgorythm2(f_SomeObject2.SomeField);
 // - тут всё хорошо, потому, что поле f_SomeObject2 инициализровано, потому, что конструктор TA зовётся ПОЗЖЕ
end;

Проблема исчезла.

Мысль понятна?

Сразу оговорюсь - "не говорите мне про C++ и другие языки". Там "по-другому" устроено.

Процитирую:

"В этом нет никакого секрета, а просто есть правило: виртуальная функция не является виртуальной, если вызывается из конструктора или деструктора.

Правило надо заучивать, что неудобно. Проще понять принцип. А принцип тут в краеугольном камне реализации наследования в C++: при создании объекта конструкторы в иерархии вызываются от базового класса к самому последнему унаследованному. Для деструкторов все наоборот.

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

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

Итак, виртуальная функция не является виртуальной, если вызывается из конструктора или деструктора."

Источник цитаты - Виртуальные функции в конструкторе и деструкторе

Это если про C++ и "другие языки".

НО!

Не про Delphi.

Теперь "пару слов" - на тему "откуда пошёл такой стиль Борладна".

А "пошло всё" из Turbo Pascal и Turbo Vision.

Там были конструкторы Init. И базовый объект TObject.

Но там была совсем ДРУГАЯ ПАРАДИГМА. Повторю - ПАРАДИГМА. И я не зря Caps Lock использовал.

Ещё раз повторю - ДРУГАЯ ПАРАДИГМА.

Что там было?

А вот что:

constructor TObject.Init;
begin
 FillChar(@Self, InstanceSize, 0);
end;

InstanceSize - конечно "выглядел иначе".

Но думаю, что "смысл понятен".

А теперь что будет с объектом наследником?

Напишем так:

type
 TA = object(TObject)
  public
   SomeField : Integer;
  public
   constructor Init;
 end;//TA

...

constructor TA.Init;
begin
 TObject.Init;
 SomeField := 123;
end;

...
var
 A : TA;
begin
 A := TA.Init;
 WriteLn(A.SomeField);
 // - Тут получаем 123
end;

А в "другой парадигме"?

type
 TA = object(TObject)
  public
   SomeField : Integer;
  public
   constructor Init;
 end;//TA

...

constructor TA.Init;
begin
 SomeField := 123;
 TObject.Init;
end;

...
var
 A : TA;
begin
 A := TA.Init;
 WriteLn(A.SomeField);
 // - Тут получаем 0
end;

Мысль понятна?

И "многие люди" до сих пор держат "в уме" эту ПАРАДИГМУ. Но при этом кстати почему-то "забывают" вызывать конструктор от TObject.

Я такое видел НЕ В ОДНОЙ сторонней библиотеке.

Например в том же ImageEn.

"Тема" конструкторов/деструкторов, фабрик и "RAII" - ещё совсем не закрыта. Она только открыта.

Если будет интерес - я напишу далее.

Но "пока" - вот "и всё что я хотел сказать о конструкторах".

Ну и "откуда всё взялось" - Коротко. О возбуждении исключений

P.S. Это всё конечно - "из-за кривой архитектуры", но это - "повод для отдельного разговора".

P.P.S. Собственно - "мысль поста" - была - БАНАЛЬНА - либо "использование фабрик", либо "слом парадигмы".

Хотя "для некоторых" и "использование фабрик" это - "слом парадигмы". К сожалению.