Проблема с полу-генерационными контейнерами в Delphi через INC-файлы: решения и обходные пути для XE2

Delphi , Программа и Интерфейс , IDE и Компилятор

В статье рассматривается проблема, связанная с использованием полу-генерационных контейнеров в Delphi, когда задействованы INC-файлы. Особое внимание уделяется версиям XE2, XE3 и XE4, поскольку именно в них возникают трудности с компиляцией зависимых INC-файлов в разделах "interface" и "implementation" модулей. Это приводит к ошибкам, когда реализация не может найти функции, объявленные в интерфейсе, так как компилятор обрабатывает INC-файлы как независимые модули.

Контекст проблемы

Использование полу-генераческих контейнеров в Delphi с помощью INC-файлов является известным трюком для создания семи-генерационных хранилищ данных. Однако, при переходе на новую версию компилятора (например, XE2), возникают проблемы с компиляцией зависимых INC-файлов. В частности, в интерфейсных и реализационных разделах модулей используются два взаимозависимых INC-файла, что приводит к ошибкам компоновки из-за того, что реализация не видит функции, объявленные в интерфейсе. Проблема не возникает всегда, но пользователю не удалось определить условия, при которых она проявляется, и найти обходной путь.

При попытке переформулировать код в терминах генератических единиц Delphi с минимальными изменениями (в рамках перехода большого наследуемого проекта на XE2, где первостепенной задачей является работоспособность, а оптимизации и рефакторинг откладываются на потом) автор столкнулся с проблемой:

TemplateList<_DATA_TYPE_> = class
public
  const
    MaxListSize = Maxint div (sizeof(Integer)*sizeof(_DATA_TYPE_));
  type
    TIntList = array[0..MaxListSize - 1] of _DATA_TYPE_;
    PIntList = ^TIntList;
  private
    FList: PIntList;
    FCount: Integer;
end;

Код вызывает ошибку, указывая на то, что нижняя граница для TIntList больше, чем верхняя. Это, по мнению автора, означает, что константа MaxListSize вычисляется в ноль, но тип TIntType пытается быть вычислен немедленно, а не при фактической инстанциации типа.

Подтвержденный ответ

Проблема заключается в том, что на этапе генерации, когда происходит компиляция, значение sizeof(_DATA_TYPE_) неизвестно. Компилятор использует в качестве заполнителя значение 0. К моменту инстанциации генераческого типа, sizeof(_DATA_TYPE_) заменяется на реальное значение, но уже поздно. Проверка границ типа массива выполняется на этапе генерации, и при этом sizeof(_DATA_TYPE_) равно 0, что приводит к ошибке компилятора.

Пример кода демонстрирует эту проблему:

type
  TemplateList<_DATA_TYPE_> = class
  public
    const
      SizeOfDataType = sizeof(_DATA_TYPE_);
      MaxListSize = Maxint div (sizeof(Integer)*SizeOfDataType);
    end;

Этот код вызывает ошибку деления на ноль. Однако, если попробовать следующий вариант:

{$APPTYPE CONSOLE}
type
  TemplateList<_DATA_TYPE_> = class
  public
    const
      SizeOfDataType = sizeof(_DATA_TYPE_);
    end;
begin
  Writeln(TemplateList<Integer>.SizeOfDataType);
  Writeln(TemplateList<Double>.SizeOfDataType);
  Readln;
end.

То вывод будет следующим:

4
8

Это показывает, что константа SizeOfDataType имеет заполнительное значение для проверки границ типа массива, но реальное значение, как только генератический тип инстанцирован. Если бы компилятор отложил проверку границ типа массива до инстанцирования, то все было бы в порядке. Однако, даже в этом случае, код не будет вести себя так, как ожидается. Пример программы:

{$APPTYPE CONSOLE}
type
  TemplateList<_DATA_TYPE_> = class
  public
    const
      SizeOfDataType = sizeof(_DATA_TYPE_);
    type
      TMyArray = array [0..SizeOfDataType] of _DATA_TYPE_;
    end;
begin
  Writeln(high(TemplateList<Integer>.TMyArray));
  Writeln(high(TemplateList<Double>.TMyArray));
  Readln;
end.

Выводит:

0
0

Это означает, что границы массива проверяются на этапе генерации, и фиксируются на этом этапе с использованием заполнительного значения размера типа параметра.

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

Альтернативный ответ

В качестве альтернативного решения автор предлагает отказаться от попытки задать границы массива и объявить его следующим образом:

type
  TemplateList<_DATA_TYPE_> = class
  public
    type
      TIntList = array[0..0] of _DATA_TYPE_;
      PIntList = ^TIntList;
    private
      FList: PIntList;
      FCount: Integer;
    end;
end;

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

Вывод

Использование полу-генерационных контейнеров в Delphi через INC-файлы может привести к ошибкам в версиях XE2, XE3 и, возможно, XE4. Проблема связана с тем, что компилятор не может корректно обработать зависимости между INC-файлами и не может вычислить размеры типов данных на этапе генерации. В качестве временного решения предлагается отказ от использования фиксированных границ массива и использование массива нулевой длины с отключенной проверкой границ. Однако, это решение не идеально и может привести к неопределенному поведению программы при работе с некорректными индексами. Для более серьезных проектов рекомендуется обратиться к реальным контейнерам, таким как TList или TList<Integer>.

Создано по материалам из источника по ссылке.

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

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: IDE и Компилятор ::