Out — Директива Delphi


Содержание

Out — Директива Delphi

директивы условной компиляции

<$C+>и <$C->— директивы проверки утверждений
<$I+>и <$I->— директивы контроля ввода/вывода
<$M>и <$S>— директивы, определяющие размер стека
<$M+>и <$M->— директивы информации времени выполнения о типах
<$Q+>и <$Q->— директивы проверки переполнения целочисленных операций
<$R>— директива связывания ресурсов
<$R+>и <$R->— директивы проверки диапазона
<$APPTYPE CONSOLE>— директива создания консольного приложения

1) Директивы компилятора, разрешающие или запрещающие проверку утверждений

По умолчанию <$C+>или

Область действия локальная

Директивы компилятора $C разрешают или запрещают проверку утверждений. Они влияют на работу процедуры Assert,используемой при отладке программ. По умолчанию действует

директива <$C+>и процедура Assert генерирует исключение EAssertionFailed, если проверяемое утверждение ложно.

Так как эти проверки используются только в процессе отладки программы, то перед ее окончательной компиляцией следует указать директиву <$C->. При этом работа процедур Assert будет блокировано и генерация исключений EassertionFailed производиться не будет.

Директивы действуют на весь файл исходного кода независимо от того, в каком месте файла они расположены.

2) Директивы компилятора, включающие и выключающие контроль файлового ввода-вывода

По умолчанию <$I+>или

Область действия локальная

Директивы компилятора $I включают или выключают автоматический контроль результата вызова процедур ввода-вывода Object Pascal. Если действует директива <$I+>, то при возвращении процедурой ввода-вывода ненулевого значения генерируется исключение EInOutError и в его свойство errorcode заносится код ошибки. Таким образом, при действующей директиве <$I+>операции ввода-вывода располагаются в блоке try. except, имеющем обработчик исключения EInOutError. Если такого блока нет, то обработка производится методом TApplication.HandleException.

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

В этом примере на время открытия файла отключается проверка ошибок ввода вывода, затем она опять включается, переменной i присваивается значение, возвращаемое функцией IOResult и, если это значение не равно нулю (есть ошибка), то предпринимаются какие-то действия в зависимости от кода ошибки. Подобный стиль программирования был типичен до введения в Object Pascal механизма обработки исключений. Однако сейчас, по-видимому, подобный стиль устарел и применение директив $I потеряло былое значение.

3) Директивы компилятора, определяющие размер стека

Область действия глобальная

Локальные переменные в процедурах и функциях размещаются в стеке приложения. При каждом вызове процедуры или функции ее локальные переменные помещаются в стек. При выходе из процедуры или функции эти локальные процедуры удаляются из стека. Директивы компилятора $M задают параметры стека приложения: его минимальный и максимальный размеры. Приложение всегда гарантированно имеет размер стека, равный его минимальной величине. Если при запуске приложения Windows обнаруживает, что не может выделить этот минимальный объем памяти, то выдается сообщение об этой ошибке.

Если во время работы выясняется, что минимального размера стека не хватает, то размер увеличивается на 4 K, но не более, чем до установленного директивой максимального размера. Если увеличение размера стека невозможно из-за нехватки памяти или из-за достижения его максимальной величины, генерируется исключение EStackOverflow. Минимальный размер стека по умолчанию равен 16384 (16K). Этот размер может изменяться параметром minstacksize директивы <$M>или параметром number директивы <$MINSTACKSIZE>.

Максимальный размер стека по умолчанию равен 1,048,576 (1M). Этот размер может изменяться параметром maxstacksize директивы <$M>или параметром number директивы <$MAXSTACKSIZE number>. Значение минимального размера стека может задаваться целым числом в диапазоне между1024 и 2147483647. Значение максимального размера стека должно быть не менее минимального размера и не более 2147483647. Директивы задания размера стека могут включаться только в программу и не должны использоваться в библиотеках и модулях.

В Delphi 1 имеется процедура компилятора <$S>, осуществляющая переключение контроля переполнения стека. Теперь этот процесс полностью автоматизирован и директива <$S>оставлена только для обратной совместимости.

4) Директивы компилятора, включающие и выключающие генерацию информации времени выполнения о типах (runtime type information — RTTI)

По умолчанию <$M->или

Область действия локальная

Директивы компилятора $I включают или выключают генерацию информации времени выполнения о типах (runtime type information — RTTI). Если класс объявляется в состоянии <$M+>или является производным от класса объявленного в этом состоянии, то компилятор генерирует RTTI о его полях, методах и свойствах, объявленных в разделе published. В противном случае раздел published в классе не допускается. Класс TPersistent, являющийся предшественником большинства классов Delphi и все классов компонентов, объявлен в модуле Classes в состоянии <$M+>. Так что для всех классов, производных от него, заботиться о директиве <$M+>не приходится.

5) Директивы компилятора, включающие и выключающие проверку переполнения при целочисленных операциях

По умолчанию <$Q->или

Область действия локальная

Директивы компилятора $Q включают или выключают проверку переполнения при целочисленных операциях. Под переполнением понимается получение результата, который не может сохраняться в регистре компьютера. При включенной директиве <$Q+>проверяется переполнение при целочисленных операциях +, -, *, Abs, Sqr, Succ, Pred, Inc и Dec. После каждой из этих операций размещается код, осуществляющий соответствующую проверку. Если обнаружено переполнение, то генерируется исключение EIntOverflow. Если это исключение не может быть обработано, выполнение программы завершается.

Директивы $Q проверяют только результат арифметических операций. Обычно они используются совместно с директивами <$R>, проверяющими диапазон значений при присваивании. Директива <$Q+>замедляет выполнение программы и увеличивает ее размер. Поэтому обычно она используется только во время отладки программы. Однако, надо отдавать себе отчет, что отключение этой директивы приведет к появлению ошибочных результатов расчета в случаях, если переполнение действительно произойдет во время выполнении программы. Причем сообщений о подобных ошибках не будет.

6) Директива компилятора, связывающая с выполняемым модулем файлы ресурсов

Область действия локальная

Директива компилятора <$R>указывает файлы ресурсов (.DFM, .RES), которые должны быть включены в выполняемый модуль или в библиотеку. Указанный файл должен быть файлом ресурсов Windows. По умолчанию расширение файлов ресурсов — .RES. В процессе компоновки компилированной программы или библиотеки файлы, указанные в директивах <$R>, копируются в выполняемый модуль. Компоновщик Delphi ищет эти файлы сначала в том каталоге, в котором расположен модуль, содержащий директиву <$R>, а затем в каталогах, указанных при выполнении команды главного меню Project | Options на странице Directories/Conditionals диалогового окна в опции Search path или в опции /R командной строки DCC32.

При генерации кода модуля, содержащего форму, Delphi автоматически включает в файл .pas директиву <$R *.DFM>, обеспечивающую компоновку файлов ресурсов форм. Эту директиву нельзя удалять из текста модуля, так как в противном случае загрузочный модуль не будет создан и сгенерируется исключение EResNotFound.

7) Директивы компилятора, включающие и выключающие проверку диапазона целочисленных значений и индексов

По умолчанию <$R->или

Область действия локальная

Директивы компилятора $R включают или выключают проверку диапазона целочисленных значений и индексов. Если включена директива <$R+>, то все индексы массивов и строк и все присваивания скалярным переменным и переменным с ограниченным диапазоном значений проверяются на соответствие значения допустимому диапазону. Если требования диапазона нарушены или присваиваемое значение слишком велико, генерируется исключение ERangeError. Если оно не может быть перехвачено, выполнение программы завершается.

Проверка диапазона длинных строк типа Long strings не производится. Директива <$R+>замедляет работу приложения и увеличивает его размер. Поэтому она обычно используется только во время отладки.

8) Директива компилятора, связывающая с выполняемым модулем файлы ресурсов

Область действия локальная

Директива компилятора <$R>указывает файлы ресурсов (.DFM, .RES), которые должны быть включены в выполняемый модуль или в библиотеку. Указанный файл должен быть файлом ресурсов Windows. По умолчанию расширение файлов ресурсов — .RES. В процессе компоновки компилированной программы или библиотеки файлы, указанные в директивах <$R>, копируются в выполняемый модуль. Компоновщик Delphi ищет эти файлы сначала в том каталоге, в котором расположен модуль, содержащий директиву <$R>, а затем в каталогах, указанных при выполнении команды главного меню Project | Options на странице Directories/Conditionals диалогового окна в опции Search path или в опции /R командной строки DCC32.

При генерации кода модуля, содержащего форму, Delphi автоматически включает в файл .pas директиву <$R *.DFM>, обеспечивающую компоновку файлов ресурсов форм. Эту директиву нельзя удалять из текста модуля, так как в противном случае загрузочный модуль не будет создан и сгенерируется исключение EResNotFound.

Delphi. Условная компиляция. Краткий справочник

Условная компиляция предназначена для управления компиляцией программного кода. В Delphi имеется несколько способов её реализации, но в основном используются только четыре.

В этой реализации условная директива <$IFDEF …>проверяет, был ли определён указанный в ней символ условной компиляции. Если да, то код программы между директивами <$IFDEF …>и <$ENDIF>компилируется. В противном случае, код между этими двумя директивами компилироваться не будет.

Эта реализация отличается от предыдущей наличием директивы <$ELSE>. В этом случае, если условный оператор определён, будет компилироваться код программы между директивами <$IFDEF>и <$ELSE>. В противном случае, будет компилироваться код программы между директивами <$ELSE>и <$ENDIF>.

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

Как определить символ условной компиляции? Для этого также существует два способа.

Первый – использование директивы

Второй способ. Определить его в свойствах проекта. Для этого в меню Project нужно выбрать пункт Options и в поле Conditional defines ввести символ условной компиляции.

Третий и четвёртый способы являются аналогией первого и второго соответственно. Отличие в том, что используется условная директива <$IFNDEF>. Эта директива проверяет, что указанный символ не определён. То есть, является прямой противоположностью директивы <$IFDEF>.

В случае <$IFNDEF>, код между этой директивой и <$ENDIF>либо <$ELSE>будет скомпилирован, только если указанный в ней символ условной компиляции не определён. В остальном, принцип реализации аналогичен приведённому для директивы <$IFDEF>:

В Delphi уже имеется ряд символов условной компиляции. Вот их «классический» набор.

Значение
MSWINDOWS Код компилируется только в ОС Windows
WIN32 То же самое, только код компилируется лишь для 32-разядной ОС.
LINUX Был введён в Delphi 6 вместе с MSWINDOWS для определения платформы, для которой необходимо компилировать тот или иной код.Так как компиляция для Linux в Delphi до сих пор отсутствует, то использование этого символа в программах не имеет смысла.
CONSOLE Консольное приложение
CPU386 Компиляция для процессоров типа i386 или более современных. Так как речь идёт о процессорах типа i386, использование данного символа уже давно потеряло актуальность.
CONDITIONAL EXPRESSIONS Проверяет использование директив $IF

Также в число «классических» входит и символ VERxxx, который указывает конкретную версию компилятора. По сути, это целое семейство символов условной компиляции, в которое с выходом новой версии Delphi добавляется новый символ соответствующий этой версии. Ниже представлена таблица соответствия версий Delphi символам условной компиляции VERxxx (материал взят с Исходники.ру).

Символ условной компиляции
1 VER80
2 VER90
3 VER100
4 VER120
5 VER130
6 VER140
7 VER150
8 VER160
2005 VER170
2006 VER180
2007* VER180 или VER185
2009 VER200
2010 VER210
XE VER220
XE2 VER230
XE3 VER240
XE4 VER250
XE5 VER260
XE6 VER270
XE7 VER280
XE8 VER290
10 Seatle VER300
10.1 Berlin VER310
10.2 Tokyo VER320

*-версии 2006 и 2007 совместимы между собой на уровне двоичного кода. Поэтому, для поддержки обеих версий следует использовать символ VER180. Если необходима поддержка только версии 2007, необходимо использовать символ VER185.

После выхода в 2011 году кроссплатформенной библиотеки FireMonkey, были введены новые символы условной компиляции для MacOS и iOS. А, в 2013 году с появлением поддержки Android был введён и специальный символ условной компиляции для этой ОС. Ниже представлен перечень этих символов.

Символ условной компиляции
MacOS MACOS
iOS IOS
Android ANDROID

Условная компиляция на примере кроссплатформенного приложения:

Заголовок и стандартные директивы

Delphi , Компоненты и Классы , Процедуры и Функции

Заголовок процедуры имеет вид:

Здесь — имя подпрограммы (правильный идентификатор);

— список формальных параметров; — тип возвращаемого функцией результата.

Сразу за заголовком подпрограммы может следовать одна из стандартных директив assembler, external, far, forward, inline, interrupt, near. Эти директивы уточняют действия компилятора и распространяются на всю подпрограмму и только на нее, т. е., если за подпрограммой следует другая подпрограмма, стандартная директива, указанная за заголовком первой, не распространяется на вторую.

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

external — с помощью этой директивы объявляется внешняя подпрограмма.

far — компилятор должен создавать код подпрограммы, рассчитанный на дальнюю модель вызова. Директива near заставит компилятор создать код, рассчитанный на ближнюю модель памяти. Введены для совместимости с Delphi 1, которая использовала сегментную модель памяти.

forward — используется при опережающем описании (см. п. 8.6) для сообщения компилятору, что описание подпрограммы следует где-то дальше по тексту программы (но в пределах текущего прораммного модуля).

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

  • interrupt — используется при создании процедур обработки прерываний.
  • Помимо описанных в Object Pascal можно использовать также стандартные директивы, регламентирующие способ передачи параметров через стек и использование регистров для их передачи — такие директивы используются при работе с ядром Windows. Они перечислены в приводимой ниже таблице. Графа порядок определяет порядок размещения параметров в стеке: слева направо означает размещение в стеке по порядку описания — сначала первый параметр, затем второй и т. д.; справа налево означает размещение с конца перечисления параметров — сначала последний, затем предпоследний и т. д. Графа Очистка определяет, кто будет очищать стек: подпрограмма перед передачей управления в вызывающую программу или программа после получения управления. Графа регистры содержит да, если для передачи параметров помимо стека используются также регистры центрального процессора.

    Таблица 8.1. Стандартные директивы, регламентирующие способ передачи параметров через стек и использование регистров для их передачи

    Все фуйкции API ядра Wmdows;скомпилированы .в режиме stidcall, а те, что доддерживают технологию СОМ — в режиме sаfеса11.

    Статья Заголовок и стандартные директивы раздела Компоненты и Классы Процедуры и Функции может быть полезна для разработчиков на Delphi и FreePascal.

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

    Материалы статей собраны из открытых источников, владелец сайта не претендует на авторство. Там где авторство установить не удалось, материал подаётся без имени автора. В случае если Вы считаете, что Ваши права нарушены, пожалуйста, свяжитесь с владельцем сайта.

    Что директива SafeCall?

    Я работаю на создание ActiveX EXE с помощью VB6, и единственный пример, который я получил это все написано в Delphi.

    Чтение примера кода, я заметил , что некоторые функции, о которых следует директива SafeCall ключевого словом. Вот пример:

    Какова цель этого ключевого слова?

    Кроме того, межсетевые экраны исключения работают по телефону SetErrorInfo () с объектом, который поддерживает IErrorInfo, так что абонент может получить дополнительную информацию об исключении. Это делается с помощью TObject.SafeCallException переопределения в обоих TComObject и TAutoIntfObject. Оба этих типов также осуществлять ISupportErrorInfo отметить этот факт.

    В случае исключения, позвонивший метода ; директивы SafeCall может запросить ISupportErrorInfo, то запрос , что для интерфейса, метод которого в результате сбоя HRESULT (старший бит комплект), и , если это возвращает S_OK, GetErrorInfo () можно получить информацию об исключении ( описание, помощь и т.д., в форме реализации IErrorInfo , который был передан в SetErrorInfo () по Delphi RTL в SafeCallException переопределениях).

    Передает параметры директивы SafeCall справа налево, вместо того, чтобы паскаль или регистра (по умолчанию) слева направо

    С директивой SafeCall, процедура или функция удаляет параметры из стека после возвращения (как паскаль, но не так, как Cdecl, где он до вызывающего)

    Директива SafeCall реализует исключения «брандмауэры»; особенно на Win32, это реализует межпроцессный COM уведомления об ошибке. Было бы иначе быть идентичен STDCALL (другое соглашения о вызовах, используемом с Win API)

    Что Francois сказал , и если бы не было директивой SafeCall ваш вызов метода COM выглядел бы , как показано ниже , и вы должны сделать проверку самостоятельно ошибки вместо того , чтобы получать исключения.

    В COM, каждый метод является функцией , которая возвращает HRESULT :

    Это абсолютное правило в COM:

    • нет никаких исключений в COM
    • все возвращает HRESULT
    • отрицательное значение HRESULT указывает на неисправность
    • языки более высокого уровня, сбои отображаются в исключения

    Это было намерение COM — дизайнеров, высокоуровневые языки будут автоматически переводить Failed методов в виде исключение.

    Так что в вашем родном языке, то COM вызов будет представлен без HRESULT. Например:

    • Delphi, как : function AddSymbol(ASymbol: OleVariant): WordBool;
    • C # -как : WordBool AddSymbol(OleVariant ASymbol);

    В Delphi вы можете использовать необработанную сигнатуру функции:

    И справиться с поднятием исключений себя:

    или сокращенный эквивалент:

    или сокращенный эквивалент:

    COM не собирался вам иметь дело с значением HRESULT

    Но вы можете спросить, Delphi, чтобы скрыть эту сантехнику от вас, так что вы можете получить с программированием:

    За кулисами, компилятор все равно будет проверять возвращаемое значение HRESULT, и бросить EOleSysError исключение , если HRESULT указывают на отказ (т.е. был отрицательным). Компилятор сгенерированной директивы SafeCall версия функционально эквивалентна:

    Но это освобождает вас просто позвонить:

    ТЛ; др: Вы можете использовать:

    Но бывший требует, чтобы обрабатывать значения HRESULT каждый раз.

    Бонус Болтовня

    Вы почти никогда не хотите обрабатывать значения HRESULT самостоятельно; она загромождает Программа с шумом, который ничего не добавляет. Но иногда вы можете проверить HRESULT самостоятельно (например, вы хотите, чтобы обрабатывать отказ, который не является очень исключительным). Никогда версии Delphi были включены начиная переведены интерфейсы заголовков для Windows, которые заявлены в обоих направлениях:

    или от источника RTL:

    SC суффикс означает директиву SafeCall . Оба интерфейса эквивалентны, и вы можете выбрать, чтобы объявить переменную COM в зависимости от Вашего желания:

    Вы даже можете бросить между ними:

    Дополнительный бонус Болтовня — C #

    C # по умолчанию делает эквивалент Delphi директивы SafeCall , за исключением C #:

    • Вы должны отказаться от отображения директивы SafeCall
    • а не отказ в

    В C # вы бы объявить COM-интерфейс, как:

    Вы заметите , что COM HRESULT скрыт от вас. C # компилятор, как компилятор Delphi, будет автоматически проверять возвращаемое значение HRESULT и бросить исключение для вас.

    И в C #, как и в Delphi, вы можете справиться с значения HRESULT себя:

    [PreserveSig] сообщает компилятору , чтобы сохранить подпись метода точно так , как это:

    Указывает ли неуправляемых методов , которые имеют HRESULT или RetVal возвращаемые значения непосредственно переводятся , или HRESULT или RetVal возвращаемые значения автоматически преобразуются в исключения.

    Условная компиляция в Delphi

    Условная компиляция в Delphi, по сути, очень полезная и удобная возможность, которая позволяет Delphi компилировать или не компилировать код в зависимости от определенных символов условной компиляции. Говоря более простым языком (возможно и не совсем корректно), условная компиляция позволяет убрать или, наоборот, добавить часть кода исполняемого файла. Так или иначе, любой Delphi разработчик встречается с символами условной компиляции как минимум один раз за время работы над проектом.

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

    Для начала, рассмотрим очень простой код, который вы можете повторить в Delphi за несколько секунд:

    Теперь нажмите F9 и проверьте, что написано в отладчике в «Events»:

    Разберемся с тем, что мы только что написали.

    $IFDEF — это директива компилятора;

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

    Процедура отправляет строку в отладчик для отображения.

    Завершает условную компиляцию, инициированную последней директивой <$IFxxx>(почему не <$IFDEF>— смотрим далее).

    Таким образом, используя директивы и мы указали компилятору дословно следующее: если где-либо по ходу компиляции был встречено условное определение DEBUG, то надо выполнить OutputDebugString.

    Где определено условное определение DEBUG? Конкретно в этом случае, символ DEBUG можно найти, если зайти в настройки проекта: Project -> Options ->Delphi Compiler :

    Здесь же можно определить и свои собственные символы. Давайте, например, добавим свой символ условной компиляции TEST. Для этого открываем диалоговое окно редактирования символов условной компиляции (жмем кнопку «…» в строке «Conditional defines») и заносим наш символ в список:

    Теперь изменим наш код, приведенный в начале статьи, чтобы он работал с нашим символом условной компиляции:

    Теперь можете снова запустить приложения в режиме отладки и посмотреть, что в Events появится строка «TEST IS ON».

    Илон Маск рекомендует:  IntToStr - Функция Delphi

    Сейчас мы с вами рассмотрели самый простой способ использования условной компиляции в Delphi — использование директив и , а также определение собственного символа условной компиляции через свойства проекта. Вместе с этим, определить (включить) свой символ условной компиляции можно и в коде программы. Для этого используется директива компилятора . Воспользуемся этой директивой:

    Соответственно, если есть директива определения нового символа, то должна быть и директива, которая отключает символы условной компиляции — она называется . Можете написать, например, вот такой код:

    и убедиться, что символ DEBUG выключен, а в окне Events не появится строка «debug is on».

    Двигаемся далее. Что делать, если нам необходимо вывести строку не когда символ включен, а именно тогда, когда он выключен? Здесь, опять же, есть варианты. Короткий вариант — воспользоваться директивой противоположной — она называется и код между и выполняется, если символ выключен:

    Второй вариант — использование директивы , если в зависимости от состояния символа условной компиляции вам надо выполнять различные участки кода:

    Соответственно, нет необходимости далее повторять этот же участок кода с использованием — работать будет, но прямо противоположно.

    Также следует обратить внимание на то, что все условные символы оцениваются в Delphi, когда вы выполняете Build проекта. Справка Delphi рекомендует для надежности пользоваться командой Project -> Build All Projects, чтобы быть уверенным, что все символы условной компиляции определены верно.

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

    Например, символ условной компиляции VER330 определен для Delphi 10.3 Rio и с его помощью можно определить какой код должен или не должен выполняться, в случае, если версия компилятора Delphi — 33. Например, воспользуемся фичей Delphi 10.3 Rio под названием Inline Variable Declaration:

    Сразу может возникнуть вопрос: как сделать так, чтобы приведенный выше код сработал не только в Delphi 10.3 Rio, но и в последующих версиях?
    Это можно сделать воспользовавшись, например, такой конструкцией:

    Здесь мы уже воспользовались директивой с помощью которой проверили значение константы CompilerVersion, которая находится в модуле System.

    Здесь же стоит обратить внимание и на окончание блока — мы использовали директиву , как того требовала Delphi до версии Delphi XE4:

    • для директивы $IFDEF должна быть определена директива $ENDIF
    • для директивы $IF должна быть определена директива $IFEND

    В XE4 нам разрешили использовать для закрытия блоков <$IF>, и . Однако, если у вас возникают проблемы при использовании связки и , то вы можете использовать специальную директиву , чтобы потребовать использовать для именно <$IFEND>:

    Теперь, если в коде выше использовать директиву $ENDIF, то получим сообщение об ошибке:

    Директиву , кстати, можно использовать и с другими константами проекта, например, так:

    Так как наша константа Version содержит значение 2, то выполнится участок кода расположенный после . Можете сменить значение константы Version на 1, чтобы убедиться, что выполнится участок кода, где определена переменная s.

    Как я сказал выше, в Delphi есть целый набор предопределенных символов условной компиляции. Ознакомиться со всеми этими символами вы можете на этой странице справки по Delphi.

    1. Использование условной компиляции позволяет нам выполнять тот или иной код, в зависимости от того, какие константы и символы условной компиляции определены или не определены в проекте.
    2. Используя предопредленные символы условной компиляции можно указывать Delphi какой код необходимо выполнить, например, если программа собирается под Android, или, если поддерживается архитектура x64 и т.д.
    3. Директива $IF может использоваться с различными константами, в том числе и определенными самим разработчиком.

    При подготовке статьи использовалась следующая информация официальной справки по Delphi:

    Out — Директива Delphi

    Профиль
    Группа: Участник Клуба
    Сообщений: 3497
    Регистрация: 31.3.2002
    Где: Лес

    Репутация: 14
    Всего: 115

    Профиль
    Группа: Участник
    Сообщений: 291
    Регистрация: 17.3.2003

    Репутация: нет
    Всего: 4

    директивы условной компиляции
    <$C+>и <$C->— директивы проверки утверждений
    <$I+>и <$I->— директивы контроля ввода/вывода
    <$M>и <$S>— директивы, определяющие размер стека

    <$M+>и <$M->— директивы информации времени выполнения о типах
    <$Q+>и <$Q->— директивы проверки переполнения целочисленных операций

    <$R>— директива связывания ресурсов

    <$R+>и <$R->— директивы проверки диапазона

    <$APPTYPE CONSOLE>— директива создания консольного приложения

    1) Директивы компилятора, разрешающие или запрещающие проверку утверждений.

    По умолчанию <$C+>или

    Область действия локальная

    Директивы компилятора $C разрешают или запрещают проверку утверждений. Они влияют на работу процедуры Assert,используемой при отладке программ. По умолчанию действует
    директива <$C+>и процедура Assert генерирует исключение EAssertionFailed, если проверяемое утверждение ложно.

    Так как эти проверки используются только в процессе отладки программы, то перед ее окончательной компиляцией следует указать директиву <$C->. При этом работа процедур Assert будет блокировано и генерация исключений EassertionFailed производиться не будет.

    Директивы действуют на весь файл исходного кода независимо от того, в каком месте файла они расположены.

    2) Директивы компилятора, включающие и выключающие контроль файлового ввода-вывода.

    По умолчанию <$I+>или

    Область действия локальная

    Директивы компилятора $I включают или выключают автоматический контроль результата вызова процедур ввода-вывода Object Pascal. Если действует директива <$I+>, то при возвращении процедурой ввода-вывода ненулевого значения генерируется
    исключение EInOutError и в его свойство errorcode заносится код ошибки. Таким образом, при действующей директиве <$I+>операции ввода-вывода располагаются в блоке try. except, имеющем обработчик исключения EInOutError. Если такого блока нет, то обработка производится методом TApplication.HandleException.

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

    В этом примере на время открытия файла отключается проверка ошибок ввода вывода, затем она опять включается, переменной i присваивается значение, возвращаемое функцией IOResult и, если это значение не равно нулю (есть ошибка), то предпринимаются какие-то действия в зависимости от кода ошибки. Подобный стиль программирования был типичен до введения в Object Pascal механизма обработки исключений. Однако сейчас, по-видимому, подобный стиль устарел и применение директив $I потеряло былое значение.

    3) Директивы компилятора, определяющие размер стека

    Область действия глобальная

    Локальные переменные в процедурах и функциях размещаются в стеке приложения. При каждом вызове процедуры или функции ее локальные переменные помещаются в стек. При выходе из процедуры или функции эти локальные процедуры удаляются из стека.
    Директивы компилятора $M задают параметры стека приложения: его минимальный и максимальный размеры. Приложение всегда гарантировано имеет размер стека, равный его минимальной величине. Если при запуске приложения Windows обнаруживает, что не может
    выделить этот минимальный объем памяти, то выдается сообщение об этой ошибке.

    Если во время работы выясняется, что минимального размера стека не хватает, то размер увеличивается на 4 K, но не более, чем до установленного директивой максимального размера. Если увеличение размера стека невозможно из-за нехватки памяти или из-за достижения его максимальной величины, генерируется исключение EStackOverflow. Минимальный размер стека по умолчанию равен 16384 (16K). Этот размер может изменяться параметром minstacksize
    директивы <$M>или параметром number директивы <$MINSTACKSIZE>.

    Максимальный размер стека по умолчанию равен 1,048,576 (1M). Этот размер может изменяться параметром maxstacksize директивы <$M>или параметром number директивы <$MAXSTACKSIZE number>. Значение минимального размера стека может задаваться целым числом в диапазоне между1024 и 2147483647. Значение максимального размера стека должно быть не менее минимального размера и не более 2147483647. Директивы задания размера стека могут включаться только в программу и не должны использоваться в библиотеках и модулях.

    В Delphi 1 имеется процедура компилятора <$S>, осуществляющая переключение контроля переполнения стека. Теперь этот процесс полностью автоматизирован и директива <$S>оставлена только для обратной совместимости.

    4) Директивы компилятора, включающие и выключающие генерацию информации времени выполнения о типах (runtime type information — RTTI).

    По умолчанию <$M->или

    Область действия локальная

    Директивы компилятора $I включают или выключают генерацию информации времени выполнения о типах (runtime type information — RTTI). Если класс объявляется в состоянии <$M+>или является производным от класса объявленного в этом состоянии, то компилятор генерирует RTTI о его полях, методах и свойствах, объявленных в разделе published. В противном
    случае раздел published в классе не допускается. Класс TPersistent, являющийся предшественником большинства классов Delphi и все классов компонентов, объявлен в модуле Classes в состоянии <$M+>. Так что для всех классов, производных от него, заботиться о директиве <$M+>не приходится.

    5) Директивы компилятора, включающие и выключающие проверку переполнения при целочисленных операциях

    По умолчанию <$Q->или

    Область действия локальная

    Директивы компилятора $Q включают или выключают проверку переполнения при целочисленных операциях. Под переполнением понимается получение результата, который не может сохраняться в регистре компьютера. При включенной директиве <$Q+>проверяется переполнение при целочисленных операциях +, -, *, Abs, Sqr, Succ, Pred, Inc и Dec. После каждой из этих операций размещается код, осуществляющий соответствующую проверку. Если обнаружено переполнение,
    то генерируется исключение EIntOverflow. Если это исключение не может быть обработано, выполнение программы завершается.

    Директивы $Q проверяют только результат арифметических операций. Обычно они используются совместно с директивами <$R>, проверяющими диапазон значений при присваивании.
    Директива <$Q+>замедляет выполнение программы и увеличивает ее размер. Поэтому обычно она используется только во время отладки программы. Однако, надо отдавать себе отчет, что отключение этой директивы приведет к появлению ошибочных результатов расчета в случаях, если переполнение действительно произойдет во время выполнении программы. Причем сообщений о подобных ошибках не будет.

    6) Директива компилятора, связывающая с выполняемым модулем файлы ресурсов

    Область действия локальная

    Директива компилятора <$R>указывает файлы ресурсов (.DFM, .RES), которые должны быть включены в выполняемый модуль или в библиотеку. Указанный файл должен быть файлом ресурсов Windows. По умолчанию расширение файлов ресурсов — .RES. В процессе компоновки компилированной программы или библиотеки файлы, указанные в директивах <$R>, копируются в
    выполняемый модуль. Компоновщик Delphi ищет эти файлы сначала в том каталоге, в котором расположен модуль, содержащий директиву <$R>, а затем в каталогах, указанных при выполнении команды главного меню Project | Options на странице Directories/Conditionals диалогового окна в опции Search path или в опции /R командной строки DCC32.

    При генерации кода модуля, содержащего форму, Delphi автоматически включает в файл .pas директиву <$R *.DFM>, обеспечивающую компоновку файлов ресурсов форм. Эту директиву нельзя удалять из текста модуля, так как в противном случае загрузочный модуль не будет создан и генерируется исключение EResNotFound.

    7) Директивы компилятора, включающие и выключающие проверку диапазона целочисленных значений и индексов

    По умолчанию <$R->или

    Область действия локальная

    Директивы компилятора $R включают или выключают проверку диапазона целочисленных значений и индексов. Если включена директива <$R+>, то все индексы массивов и строк и все присваивания скалярным переменным и переменным с ограниченным диапазоном значений проверяются на соответствие значения допустимому диапазону. Если требования
    диапазона нарушены или присваиваемое значение слишком велико, генерируется исключение ERangeError. Если оно не может быть перехвачено, выполнение программы завершается.

    Проверка диапазона длинных строк типа Long strings не производится.
    Директива <$R+>замедляет работу приложения и увеличивает его размер. Поэтому она обычно используется только во время отладки.

    8) Директива компилятора, связывающая с выполняемым модулем файлы ресурсов

    Область действия локальная

    Директива компилятора <$R>указывает файлы ресурсов (.DFM, .RES), которые должны быть включены в выполняемый модуль или в библиотеку. Указанный файл должен быть файлом ресурсов Windows. По умолчанию расширение файлов ресурсов — .RES.
    В процессе компоновки компилированной программы или библиотеки файлы, указанные в директивах <$R>, копируются в выполняемый модуль. Компоновщик Delphi ищет эти файлы сначала в том каталоге, в котором расположен модуль, содержащий директиву <$R>, а затем в каталогах, указанных при выполнении команды главного меню Project | Options на странице Directories/Conditionals диалогового окна в опции Search path или в опции /R командной строки DCC32.

    При генерации кода модуля, содержащего форму, Delphi автоматически включает в файл .pas директиву <$R *.DFM>, обеспечивающую компоновку файлов ресурсов форм. Эту директиву нельзя удалять из текста модуля, так как в противном случае загрузочный модуль не будет создан и генерируется исключение EResNotFound.

    Программирование на языке Delphi

    Глава 5. Динамически загружаемые библиотеки


    Авторы: А.Н. Вальвачев
    К.А. Сурков
    Д.А. Сурков
    Ю.М. Четырько

    Опубликовано: 03.12.2005
    Исправлено: 10.12.2020
    Версия текста: 1.0

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

    5.1. Динамически загружаемые библиотеки

    Динамически загружаемая библиотека (от англ. dynamically loadable library) — это библиотека подпрограмм, которая загружается в оперативную память и подключается к использующей программе во время ее работы (а не во время компиляции и сборки). Файлы динамически загружаемых библиотек в среде Windows обычно имеют расширение .dll (от англ. Dynamic-Link Library). Для краткости в этой главе мы будем использовать термин динамическая библиотека, или даже просто библиотека, подразумевая DLL-библиотеку.

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

    Одно из важнейших назначений динамически загружаемых библиотек — это взаимодействие подпрограмм, написанных на разных языках программирования. Например, вы можете свободно использовать в среде Delphi динамически загружаемые библиотеки, разработанные в других системах программирования с помощью языков C и C++. Справедливо и обратное утверждение — динамически загружаемые библиотеки, созданные в среде Delphi, можно подключать к программам на других языках программирования.

    5.2. Разработка библиотеки


    5.2.1. Структура библиотеки

    По структуре исходный текст библиотеки похож на исходный текст программы, за исключением того, что текст библиотеки начинается с ключевого слова library , а не слова program . Например:

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


    Если в теле библиотеки объявлены некоторые процедуры,

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

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

    Ниже приведен пример исходного текста простейшей динамически загружаемой библиотеки SortLib. Она содержит единственную процедуру BubleSort, сортирующую массив целых чисел методом «пузырька»:

    Исходный текст динамически загружаемой библиотеки заканчивается операторным блоком begin. end , в который можно вставить любые операторы для подготовки библиотеки к работе. Эти операторы выполняются во время загрузки библиотеки основной программой. Наша простейшая библиотека SortLib не требует никакой подготовки к работе, поэтому ее операторный блок пустой.

    5.2.2. Экспорт подпрограмм

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

    В стандартном случае экспортное имя подпрограммы считается в точности таким, как ее идентификатор в исходном тексте библиотеки (с учетом заглавных и строчных букв). Например, если секция exports имеет следующий вид,

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

    В итоге, экспортное имя процедуры BubleSort будет ’BubleSortIntegers’.

    Экспортные имена подпрограмм должны быть уникальны в пределах библиотеки, поэтому их нужно всегда указывать явно для перегруженных ( overload ) процедур и функций. Например, если имеются две перегруженные процедуры с общим именем QuickSort,

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

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

    5.2.3. Соглашения о вызове подпрограмм

    В главе 2 мы уже кратко рассказывали о том, что в различных языках программирования используются различные правила вызова подпрограмм, и что для совместимости с ними в языке Delphi существуют директивы register , stdcall , pascal и cdecl . Применение этих директив становится особенно актуальным при разработке динамически загружаемых библиотек, которые используются в программах, написанных на других языках программирования.

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

    Стек — это область памяти, в которую данные помещаются в прямом порядке, а и извлекаются в обратном, по аналогии с наполнением и опустошением магазина патронов у стрелкового оружия. Очередность работы с элементами в стеке обозначается термином LIFO (от англ. Last In, First Out — последним вошел, первым вышел).

    Существует еще обычная очередность работы с элементами, обозначаемая термином FIFO (от англ. First In, First Out — первым вошел, первым вышел).

    Для каждой программы на время работы создается свой стек. Через него передаются параметры подпрограмм и в нем же сохраняются адреса возврата из этих подпрограмм. Именно благодаря стеку подпрограммы могут вызывать друг друга, или даже рекурсивно сами себя.

    Вызов подпрограммы состоит из «заталкивания» в стек всех аргументов и адреса следующей команды (для воврата к ней), а затем передачи управления на начало подпрограммы. По окончании работы подпрограммы из стека извлекается адрес воврата с передачей управления на этот адрес; одновременно с этим из стека выталкиваются аргументы. Происходит так называемая очистка стека. Это общая схема работы и у нее бывают разные реализации. В частности, аргументы могут помещаться в стек либо в прямом порядке (слева направо, как они перечислены в описании подпрограммы), либо в обратном порядке (справа налево), либо вообще, не через стек, а через свободные регистры процессора для повышения скорости работы. Кроме того, очистку стека может выполнять либо вызываемая подпрограмма, либо вызывающая программа. Выбор конкретного соглашения о вызове обеспечивают директивы register , pascal , cdecl и stdcall . Их смысл поясняет таблица 5.1.

    DriveSoftware
    Дата 22.1.2004, 14:05 (ссылка) | (нет голосов) Загрузка .
    Директива Порядок занесения аргументов в стек Кто отвечает за очистку стека Передача аргументов через регистры
    register Слева направо Подпрограмма Да
    pascal Слева направо Подпрограмма Нет
    cdecl Справа налево Вызывающая программа Нет
    stdcall Справа налево Подпрограмма Нет
    Таблица 5.1. Соглашения о вызове подпрограмм
    ПРИМЕЧАНИЕ

    Директива register не означает, что все аргументы обязательно передаются через регистры процессора. Если число аргументов больше числа свободных регистров, то часть аргументов передается через стек.

    Возникает резонный вопрос: какое соглашение о вызове следует выбирать для процедур и функций динамически загружаемых библиотек. Ответ — соглашение stdcall :

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

    5.2.4. Пример библиотеки

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

    Шаг 1. Запустите систему Delphi и выберите в меню команду File | New | Other. . В диалоговом окне, которое откроется на экране, выберите значок с подписью DLL Wizard и нажмите кнопку OK (рисунок 5.1):

    Рисунок 5.1. Окно выбора нового проекта, в котором выделен пункт DLL Wizard

    Среда Delphi создаст новый проект со следующей заготовкой библиотеки:

    Шаг 2. С помощью команды File | New | Unit создайте в проекте новый программный модуль. Его заготовка будет выглядеть следующим образом:

    Шаг 3. Сохраните модуль под именем SortUtils.pas, а проект — под именем SortLib.dpr. Прейдите к главному файлу проекта и удалите из секции uses модули SysUtils и Classes (они сейчас не нужны). Главный программный модуль должен стать следующим:

    Шаг 4. Наберите исходный текст модуля SortUtils:

    В этом модуле процедуры BubleSort и QuickSort сортируют массив чисел двумя способами: методом «пузырька» и методом «быстрой» сортировки соответственно. С их реализацией мы предоставляем вам разобраться самостоятельно, а нас сейчас интересует правильное оформление процедур для их экспорта из библиотеки.

    Директива stdcall , использованная при объявлении процедур BubleSort и QuickSort,

    позволяет вызывать процедуры не только из программ на языке Delphi, но и из программ на языках C/C++ (далее мы покажем, как это сделать).

    Благодаря присутствию в модуле секции exports ,

    подключение модуля в главном файле библиотеки автоматически приводит к экспорту процедур.

    Шаг 5. Сохраните все файлы проекта и выполните компиляцию. В результате вы получите на диске в своем рабочем каталоге двоичный файл библиотеки SortLib.dll. Соответствующее расширение назначается файлу автоматически, но если вы желаете, чтобы компилятор назначал другое расширение, воспользуйтесь командой меню Project | Options… и в появившемся окне Project Options на вкладке Application впишите расширение файла в поле Target file extension (рисунок 5.2).

    Рисунок 5.2. Окно настройки параметров проекта

    Кстати, с помощью полей LIB Prefix , LIB Suffix и LIB Version этого окна вы можете задать правило формирования имени файла, который получается при сборке библиотеки. Имя файла составляется по формуле:

    5.3. Использование библиотеки в программе

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

    • статический импорт (обеспечивается директивой компилятора external );
    • динамический импорт (обеспечивается функциями LoadLibrary и GetProcAddress ).

    Статический импорт является более удобным, а динамический — более гибким.

    5.3.1. Статический импорт

    При статическом импорте все действия по загрузке и подключению библиотеки выполняются автоматически операционной системой во время запуска главной программы. Чтобы задействовать статический импорт, достаточно просто объявить в программе процедуры и функции библиотеки как внешние. Это делается с помощью директивы external , например:

    После ключевого слова external записывается имя двоичного файла библиотеки в виде константной строки или константного строкового выражения. Вместе с директивой external может использоваться уже известная вам директива name , которая служит для явного указания экспортного имени процедуры в библиотеке. С ее помощью объявления процедур можно переписать по-другому:

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

    Шаг 6. Создайте новую консольную программу. Для этого выберите в меню команду File | New | Other. и в открывшемся диалоговом окне выделите значок Console Application . Затем нажмите кнопку OK .

    Шаг 7. Добавьте в программу external -объявления процедур BubleSort и QuickSort, а также наберите приведенный ниже текст программы. Сохраните проект под именем TestStaticImport.dpr.

    Шаг 8. Выполните компиляцию и запустите программу. Если числа печатаются на экране по возрастанию, то сортировка работает правильно.

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

    5.3.2. Модуль импорта

    При разработке динамически загружаемых библиотек нужно всегда думать об их удобном использовании. Давайте, например, обратимся к последнему примеру и представим, что в библиотеке не две процедуры, а сотня, и нужны они не в одной программе, а в нескольких. В этом случае намного удобнее вынести external -объявления процедур в отдельный модуль, подключаемый ко всем программам в секции uses . Такой модуль условно называют модулем импорта . Кроме объявлений внешних подпрограмм он обычно содержит определения типов данных и констант, которыми эти подпрограммы оперируют.

    Модуль импорта для библиотеки SortLib будет выглядеть так:

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

    5.3.3. Динамический импорт

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

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

    Ниже приведено краткое описание функций LoadLibrary , FreeLibrary и GetProcAddress .

    • LoadLibrary (LibFileName: PChar): HModule — загружает в оперативную память библиотеку, которая хранится на диске в файле с именем LibFileName . При успешном выполнении функция возвращает числовой описатель библиотеки, который должен использоваться в дальнейшем для управления библиотекой. Если при загрузке библиотеки призошла какая-нибудь ошибка, то возвращается нулевое значение. Если аргумент LibFileName содержит имя файла без маршрута, то этот файл ищется в следущих каталогах: в каталоге, из которого была запущена главная программа, в текущем каталоге, в системном каталоге операционной системы Windows (его точный маршрут можно узнать вызовом функции GetSystemDirectory ), в каталоге, по которому установлена операционная система (его точный маршрут можно узнать вызовом функции GetWindowsDirectory ), а также в каталогах, перечисленных в переменной окружения PATH .
    • FreeLibrary (LibModule: HModule): Bool — выгружает библиотеку, заданную описателем LibModule , из оперативной памяти и освобождает занимаемые библиотекой ресурсы системы.
    • GetProcAddress (Module: HModule; ProcName: PChar): Pointer — возвращает адрес подпрограммы с именем ProcName в библиотеке с описателем Module . Если подпрограмма с именем ProcName в библиотеке не существует, то функция возвращает значение nil (пустой указатель).

    Приведенная ниже программа TestDynamicImport аналогична по функциональности программе TestStaticImport , но вместо статического импорта использует технику динамического импорта:

    В программе определены два процедурных типа данных, которые по списку параметров и правилу вызова ( stdcall ) соответствуют подпрограммам сортировки BubleSort и QuickSort в библиотеке:

    Эти типы данных нужны для объявления процедурных переменных, в которых сохраняются адреса подпрограмм:

    В секции var объявлена также переменная для хранения целочисленного описателя библиотеки, возвращаемого функцией LoadLibrary :

    Программа начинает свою работу с того, что вызывает функцию LoadLibrary , в которую передает имя файла DLL-библиотеки. Функция возвращает описатель библиотеки, который сохраняется в переменной LibHandle .

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

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

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

    По окончании сортировки программа выгружает библиотеку вызовом функции FreeLibrary .

    Как вы убедились, динамический импорт в сравнении со статическим требует значительно больше усилий на программирование, но он имеет ряд преимуществ:

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

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

    5.4. Использование библиотеки из программы на языке C++

    Созданные в среде Delphi библиотеки можно использовать в других языках программирования, например в языке C++. Язык C++ получил широкое распространение как язык системного программирования, и в ряде случаев программистам приходится прибегать к нему.

    Ниже показано, как выполнить импорт подпрограмм BubleSort и QuickSort в языке C++.

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

    5.5. Глобальные переменные и константы

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

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

    5.6. Инициализация и завершение работы библиотеки

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

    Существует еще один способ инициализации и завершения библиотеки, основанный на использовании предопределенной переменной DllProc . Переменная DllProc хранит адрес процедуры, которая автоматически вызывается при отключении библиотеки от программы, а также при создании и уничтожении параллельных потоков в программах, использующих DLL-библиотеку (потоки обсуждаются в главе 14). Ниже приведен пример использования переменной DllProc :

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

    • DLL_PROCESS_DETACH — отключение программы;
    • DLL_PROCESS_ATTACH — подключение программы;
    • DLL_THREAD_ATTACH — создание параллельного потока;
    • DLL_THREAD_DETACH — завершение параллельного потока.

    Обратите внимание, что установка значения переменной DllProc выполняется в главном программном блоке, причем предыдущее значение сохраняется для вызова «по цепочке».

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

    5.7. Исключительные ситуации и ошибки выполнения подпрограмм

    Для поддержки исключительных ситуаций среда Delphi использует средства операционной системы Window. Поэтому, если в библиотеке возникает исключительная ситуация, которая никак не обрабатывается, то она передается вызывающей программе. Программа может обработать эту исключительную ситуацию самым обычным способом — с помощью операторов try … except . end . Такие правила действуют для программ и DLL-библиотек, созданных в среде Delphi. Если же программа написана на другом языке программирования, то она должна обрабатывать исключение в библиотеке, написанной на языке Delphi как исключение операционной системы с кодом $0EEDFACE. Адрес инструкции, вызвавшей исключение, содержится в первом элементе, а объект, описывающий исключение, — во втором элементе массива ExceptionInformation , который является частью системной записи об исключительной ситуации.

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

    5.8. Общий менеджер памяти

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

    Модуль ShareMem является модулем импорта динамически загружаемой библиотеки Borlndmm.dll, которая должна распространяться вместе с вашей программой. В момент инициализации модуль ShareMem выполняет подмену стандартного менеджера памяти на менеджер памяти из библиотеки Borlndmm.dll. Благодаря этому библиотека и программа могут выделять и освобождать память совместно.

    Модуль ShareMem следует подключать еще и в том случае, если между библиотекой и программой происходит передача длинных строк или динамических массивов. Поскольку длинные строки и динамические массивы размещаются в динамической памяти и управляются автоматически (путем подсчета количества ссылок), то блоки памяти для них, выделяемые программой, могут освобождаться библиотекой (а также наоборот). Использование единого менеджера памяти из библиотеки Borlndmm.dll избавляет программу и библиотеку от скрытых разрушений памяти.

    ПРИМЕЧАНИЕ

    Последнее правило не относится к отрытым массивам-параметрам, которые мы использовали в подпрограммах BubleSort и QuickSort при создании библиотеки SortLib.dll.

    5.9. Стандартные системные переменные

    Как вы уже знаете, в языке Delphi существует стандартный модуль System , неявно подключаемый к каждой программе или библиотеке. В этом модуле содержатся предопределенные системные подпрограммы и переменные. Среди них имеется переменная IsLibrary с типом Boolean, значение которой равно True для библиотеки и False для обычной программы. Проверив значение переменной IsLibrary , подпрограмма может определить, является ли она частью библиотеки.

    В модуле System объявлена также переменная CmdLine: PChar , содержащая командную строку, которой была запущена программа. Библиотеки не могут запускаться самостоятельно, поэтому для них переменная CmdLine всегда содержит значение nil .

    5.10. Итоги

    Прочитав главу, вы наверняка вздохнули с облегчением. Жизнь стала легче: сделал одну уникальную по возможностям библиотеку и вставляй ее во все программы! Нужно подключить к Delphi-программе модуль из другой среды программирования — пожалуйста! И все это делается с помощью динамически загружаемых библиотек. Надеемся, вы освоили технику работы с ними и осилите подключение к своей программме библиотек, написанных не только на языке Delphi, но и на языках C и C++. В следующей главе мы рассмотрим некоторые другие взаимоотношения между программами, включая управление объектами одной программы из другой.

    Блог GunSmoker-а

    . when altering one’s mind becomes as easy as programming a computer, what does it mean to be human.

    19 апреля 2009 г.

    Настройки проектов в Delphi с точки зрения поиска ошибок

    О чём идёт речь

    Сначала, давайте посмотрим на них: открываем Project/Options. Нас будут интересовать вкладки Compiling и Linking (в старых версиях Delphi они назывались Compiler и Linker):

    На вкладке «Compiler» нас будут интересовать опции «Stack Frames», группа «Debug information», «Local Symbols» и «Symbol reference info», «I/O Checking», «Overflow checking» и «Range checking». На «Linking» — «Map file», «Debug Information» (известная в предыдущих версиях Delphi как «Include TD32 debug info») и «Include remote debug symbols».

    Давайте посмотрим, за что отвечают эти опции. А затем — как их лучше бы всего расставить. При этом мы будем рассматривать такие ситуации: обычное приложение и приложение с механизмом диагностики исключений.
    Кроме того, настройки проекта могут отличаться, компилируете ли вы приложение для себя или для распространения. В новых версиях Delphi появились профили настроек (Debug и Release, соответственно). Вы можете задать свой набор настроек в каждом профиле, а затем переключаться между ними. В старых Delphi есть только один профиль настроек и вам нужно менять каждую настройку вручную.

    Напомним, что при смене любой из опций необходимо сделать полный Build проекту (а не просто Compile).

    Что означают эти опции?

    Самыми важными настройками являются группа опций «Debug information», «Local Symbols» и «Symbol reference info».

    Программа представляет собой набор машинных команд. Текст программы представляет собой текстовый файл. Вопрос: как отладчик узнаёт, когда надо остановиться, если вы поставили бряк на строку в тексте? Где же соответствие между текстовым файлом и набором байт в exe-файле? Вот для такой связи и служит отладочная информация. Это, грубо говоря, набор инструкций типа: «машинные коды с 1056 по 1059 относятся к строке 234 модуля Unit1.pas». Вот с помощью такой информации и работает отладчик. Указанные выше опции отвечают за генерацию отладочной информации для ваших модулей.

    Отладочная информация сохраняется вместе с кодом модуля в dcu-файле. Т.е. один и тот же Unit1.pas может быть скомпилирован как с отладочной информацией, так и без неё — в разные dcu файлы. Отладочная информация увеличивает время компиляции, размер dcu-файлов, но не влияет на размер и скорость работы полученного exe-файла (т.е. отладочная информация не подключается к exe-файлу) (*).

    Бывают ситуации, когда наличие отладочной информации в файле или (хотя бы) рядом с файлом является необходимым. Например, если вы выполняете удалённую отладку или отладку внешнего процесса. Или если вам нужен читаемый стек вызовов в вашем средстве диагностики исключений.

    Подключение отладочной информации к приложению осуществляется несколькими способами: либо это опции проекта (а именно: «Map File», «Debug information» (Linker)/«Include TD32 Debug info» или «Include remote debug symbols»), либо это возможности всевозможных экспертов (типа EurekaLog, JCL или madExcept), которые добавляют отладочную информацию в программу в своём формате.

    Итак, опции отладочной информации:

    • «Debug information» (директива <$D+>или <$D->) – это собственно и есть отладочная информация. Т.е. соответствие между текстом программы и её машинным кодом. Вы должны включить эту опцию, если хотите ставить бряки, выполнять пошаговую отладку, а также иметь стек с именами для своего кода. Часто эту опцию включают автоматически различные эксперты типа EurekaLog.
    • «Local symbols» (директива <$L+>или <$L->) – является дополнением к отладочной информации. Она отвечает за соответствие между данными в exe-файле и именами переменных. Если вы включаете эту опцию, то отладчик позволит вам просматривать и изменять переменные. Также окно «Call Stack» будет способно отражать переданные в процедуры параметры.
    • «Reference info» – это дополнительная информация для редактора кода, которая позволяет ему отображать более подробную информацию об идентификаторах. Например, где была объявлена переменная.

    Эти три опции тесно связаны и обычно нет смысла включать/выключать их по одной.

    • «Use Debug DCUs» — эта опция переключает сборку вашей программы с отладочными модулями Delphi или с обычными. Если вы внимательно посмотрите на установку Delphi, то увидите, что pas файлы из папки Source никогда не используются для компиляции — а только для отладки. Для компиляции же используются уже готовые dcu-файлы из папки Lib. Это уменьшает время компиляции. Поскольку dcu могут быть скомпилированы с отладочной информацией и без неё, то в папке Lib есть два набора dcu-файлов: обычные и отладочные. Переключая эту опцию, вы указываете, какие из них использовать. Если вы выключите эту опцию, то не сможете заходить по F7 в стандартные функции и методы Delphi (т.к. для них будет отсутствовать отладочная информация). Также при выключенной опции вы не будете видеть информацию о стандартном коде в стеке вызовов.
    • «Stack Frames» — эта опция отвечает за генерацию стековых фреймов. Если опция выключена, то стековый фрейм не генерируется без необходимости. Если она включена -то фрейм генерируется всегда. Стековые фреймы используются при построении стека вызовов по фреймам (построение методом raw-сканирование не нуждается в стековых фреймах). В обычном приложении стековые фреймы генерируются практически всегда (**).
    • «Range checking» — служит помощником в поиске проблем при работе, например, с массивами. Если её включить, то для любого кода, который работает с массивами и строками, компилятор добавляет проверочный код, который следит за правильностью индексов. Если при проверке обнаруживается, что вы вылезаете за границы массива, то будет сгенерировано исключение класса ERangeError. При этом вы можете идентифицировать ошибку обычной отладкой. Если же опция выключена, то никакого дополнительного кода в программу не добавляется. Включение опции немного увеличивает размер программы и замедляет её выполнение. Рекомендуется включать эту опцию только в отладочной версии программы.
    • «Overflow checking» — похожа на опцию «Range checking», только проверочный код добавляется для всех арифметических целочисленных операций. Если результат выполнения такой операции выходит за размерность (происходит переполнение результата), то возбуждается исключение класса EIntOverflow. Пример – к байтовой переменной, равной 255, прибавляется 2. Должно получиться 257, но это число больше того, что помещается в байте, поэтому реальный результат будет равен 1. Это и есть переполнение. Эта опция используется редко по трём причинам. Во-первых, самый разный код может рассчитывать на то, что эта опция выключена (часто это различного рода криптографические операции, подсчёт контрольной суммы и т.п., но не только). В связи с этим при включении этой опции могут начаться совершенно различные проблемы. Во-вторых, в обычных ситуациях работают с четырёхбайтовыми знаковыми величинами, и работа около границ диапазонов представления происходит редко. В-третьих, арифметические операции с целыми – достаточно частый код (в отличие от операций с массивами), и добавление дополнительной работы на каждую операцию иногда может быть заметно (в смысле производительности).
    • «I/O Checking» — эта опция используется только при работе с файлами в стиле Паскаля, которые считаются устаревшими. По-хорошему, вы не должны использовать их и, соответственно, эту опцию.

    Замечу также, что эти опции можно выставлять и локально — как для целого модуля, так и для отдельной функции/процедуры (а для некоторых опций — даже для участка кода). Делается это обычными директивами компилятора, узнать которые вы можете, нажав F1 в окне настроек. Например, «Stack Frames» регулируется <$W+>и <$W->.

    Кроме того, помимо настроек компилятора (Compiling) есть ещё настройки компоновщика (Linking):

    • «Map file» — включение опции заставляет линкёр Delphi создавать вместе с проектом map-файл. Различные установки опции отвечают за уровень детализации и обычно имеет смысл ставить только Off или Detailed. Map файл обычно используется всевозможными утилитами типа EurekaLog, JCL или madExcept в качестве первичного источника для создания отладочной информации в своём формате. Поэтому руками устанавливать эту опцию вам придётся крайне редко — эксперты включают её самостоятельно по необходимости.
    • «Debug Information» (Linker)/«Include TD32 debug info» — внедряет в приложение отладочную информацию для внешнего отладчика в формате TD32. Обычно эта опция включается, если вы отлаживаете проект через Attach to process и Delphi не может найти отладочную информацию. При включении этой опции размер самого приложения увеличивается в 5-10 раз (при условии, что опция «Place debug information in separate TDS file» выключена). Поэтому, если вам нужна отладочная информация в распространяемом приложении — лучше рассмотреть другие варианты (лучше всего подходит отладочная информация в специализированных форматах — EurekaLog, JCL, madExcept).
    • «Include remote debug symbols» — заставляет линкёр создать rsm-файл вместе с проектом, в который записывается информация для удалённого отладчика Delphi. Вам нужно включать эту опцию, если вы хотите выполнить удалённую отладку. Полученный rsm-файлик нужно копировать вместе с приложением на удалённую машину.

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

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

    Обычное приложение без механизма диагностики исключений

    Общие настройки для любых профилей

    Все опции отладки («Debug information» (Compiler), «Local symbols», «Reference info») вообще на готовый модуль не влияют, т.к. отладочная информация в exe/DLL не хранится, ну и нам жить не мешают => поэтому смысла их выключать я не вижу («Use Debug DCUs» — устанавливайте по вкусу, смотря по тому, хотите вы отлаживаться в стандартных модулях или нет).

    «Stack Frames» вообще включать незачем.

    Генерацию map-файла выключаем.

    Профиль Debug

    Включаем «Range checking» и (по вкусу) «Overflow checking».

    «Include TD32 debug info» — включаем только для отладки внешнего процесса.

    Соответственно, «Include remote debug info» — включаем только для удалённой отладки.

    Профиль Release

    Выключаем «Range checking», «Overflow checking», «Include TD32 debug info» и «Include remote debug info».

    Приложение с механизмом диагностики исключений (типа EurekaLog, JCL или madExcept)

    Общие настройки любых профилей

    Все опции отладки («Debug information» (Compiler), «Local symbols», «Reference info») держать включёнными, т.к. в противном случае не будет доступна отладочная информация. Соответственно, ваши информационные механизмы пойдут лесом.

    «Stack Frames» — вообще вЫключать незачем.

    Генерацию map-файла включаем, если об этом не позаботился эксперт (маловероятно).

    Профиль Debug

    «Use Debug DCUs» — по вкусу.
    Включаем «Range checking» и (по вкусу) «Overflow checking».

    «Include TD32 debug info» — включаем только для отладки внешнего процесса.

    «Include remote debug info» — включаем только для удалённой отладки.

    Профиль Release

    Включаем «Use Debug DCUs».

    Выключаем «Range checking», «Overflow checking», «Include TD32 debug info» и «Include remote debug info».

    Примечание: если вы используете мало операций с индексами в своей программе (так что дополнительные проверки не замедлят её), то будет хорошей идеей всегда держать опцию «Range checking» включённой.

    Что может пойти не так, если настройки будут заданы неверно?

    Ну, во-первых, это невозможность отладки (например, отсутствие информации для удалённого отладчика или выключенная опция «Debug information» (Compiler)), большой размер приложения (например, случайно забыли выключить «Debug information» (Linker)/«Include TD32 debug info»), медленная работа (например, компиляция с отладочным кодом), отсутствие или неполный стек вызовов в средствах диагностики исключений (например, выключили «Debug information» (Compiler)). В очень редких и запущенных случаях переключение опций может сказаться на работоспособности программы (например, установка Stack frames может снизить максимально возможную глубину рекурсии). Ну и недочёты по мелочи.

    Кстати, если вы разрабатываете компоненты, то надо учитывать, что у Delphi есть именно два набора DCU-файлов, которые отличаются настройками компиляции. Вообще говоря, простое переключение опций, ответственных за генерацию отладочной информации, никак не влияет на интерфейс и реализацию модуля. Но в общем случае код может использовать условные директивы. Поэтому может быть ситуация, когда два набора DCU файлов (скомпилированных с разными опциями) не совместимы друг с другом — потому что они использовали какую-либо директиву и содержат разный код (а вот и пример).
    Поэтому вам тоже надо иметь два набора DCU-файлов: один — скомпилированный с опцией «Use Debug DCUs», другой — без. Причём, не важно включена или выключена опция «Debug information» (Compiler) в ваших настройках в обоих случаях.

    Примечания:
    (*) Слова «отладочная информация увеличивает время компиляции, размер dcu-файлов, но не влияет на размер и скорость работы полученного exe-файла» некоторые понимают неправильно. В частности, многие замечают, что если переключить профиль приложения с Debug на Release (или наоборот), то размер приложения изменится (незначительно или же намного — зависит от настроек проекта и его исходного кода). Позвольте, но ведь я говорю об отладочной информации в чистом виде (мы говорим про опции «Debug Information», «Local Symbols» и т.п. с вкладки «Compiling»), а вы меняете профиль компиляции целиком. Это не только смена опций отладочной информации (которые, кстати, могут даже вообще не меняться при смене профиля), а также и множество других настроек.

    Например, в вашем коде может быть тьма конструкций вида <$IFDEF DEBUG>какой-то код <$ENDIF>. Разумеется, когда вы собираете программу в Release, этот код в программу не попадёт, а когда вы собираете его в Debug, то — попадёт. Потому что по умолчанию профиль Debug содержит символ условной компиляции «DEBUG». В результате размер .exe действительно получится разный. Но повлияла ли на этот размер отладочная информация? Неа. Фактически, вы собрали в разных профилях разных код — неудивительно, что он разный по размеру.

    Более того, вы можете удалить из конфигурации Debug символ условной компиляции «DEBUG» — и тогда вы будете собирать один и тот же код в обоих профилях. Ну, по крайней мере, свой код. Сторонний, уже собранный код, конечно же, никак не будет затронут. Например, код RTL/VCL уже скомпилирован с фиксированными настройками и не меняется при пересборке проекта. Вон там чуть выше я упомянул, что в некоторых версиях Delphi отладочный и релизный варианты кода RTL/VCL незначительно отличаются — опять же, благодаря условной компиляции. Но никак не отладочной информации.

    Кроме того, к иному коду приводит и включение/выключение опций вида Optimization, Stack Frames, Range Check Errors и др. Действительно, оптимизация может удалять код (оптимизировать ненужный) или увеличивать (вставлять inline вместо вызова), Stack Frames очевидно добавляет код (код установки фрейма), равно как и Range Check Errors (код проверки диапазонов). В результате, вы меняете профиль — вы меняете и код (при условии, что разные профили имеют разные настройки вышеупомянутых опций — что так и есть по умолчанию). Меняете код — меняете и размер. Имеет ли хоть какое-то отношение к этому изменению размера отладочная информация? Нет.

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

    Также о внедрении отладочной информации можно попросить и среду. Например, вы можете включить «Include TD32 Debug Info» (эта опция называется «Debug Information» на вкладке «Linking» в последних версиях Delphi) и выключить опцию «Place debug information in separate TDS file». Тогда вся отладочная информация из .dcu файлов будет собрана в один большой файл и этот файл будет внедрён в .exe. Тогда да, отладочная информация повлияет на размер файла, но это происходит не из-за её свойств, а потому что мы явно попросили такое поведение: «добавьте отладочную инфу в мою программу».

    Кстати говоря, в последних версиях Delphi здорово поменяли настройки профилей компиляции. Если раньше Release и Debug мало чем отличались, то теперь отличия существенны. Профиль Debug выключает Optimization, но включает Stack Frames (а профиль Release — делает наоборот). Профиль Debug включает отладочную информацию, а Release — отключает. Но оба профиля включают Assert-ы. Также оба профиля включают I/O checks, но выключают overflow и range. В настройках компоновщика (linking) профиль Debug включает TD32 («Debug information») и Remote debug symbols (не для всех платформ). Release, соответственно, выключает эти же опции. И оба профиля не включают Map file и отдельный файл для TD32.

    (**) Например: Button1Click состоит всего из двух инструкций: «call A; ret;». Она очень короткая и не использует аргументы или локальные переменные. Поэтому, очевидно, что ей не нужен стековый фрейм. Когда опция «Stack frames» выключена, то для Button1Click стековый фрейм не создаётся (но он создаётся, если опция «Stack frames» будет включена).

    Но, для более сложных процедур стековые фреймы будут генерироваться вне зависимости от установки опции «Stack frames».

    Например, тоже очень короткая процедура B всегда имеет фрейм. Причина: использование типа String в ShowMessage. Компилятору нужно вставить неявную строковую переменную и неявный try/finally для её освобождения, поэтому процедуре нужен фрейм.

    В реальных приложениях фреймы генерируются для 99% процедур. Подробнее: Фреймы на стеке.

    Блог GunSmoker-а (переводы)

    . when altering one’s mind becomes as easy as programming a computer, what does it mean to be human.

    среда, 13 июля 2011 г.

    Виртуальные методы и inherited

    Это перевод Virtual methods and inherited. Автор: Hallvard Vassbotn.

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

    Виртуальный метод объявляется в своём базовом классе с использованием директивы virtual : Базовый класс может иметь реализацию по умолчанию для виртуального метода, а может и не иметь. Если реализации по умолчанию нет, то вы помечаете метод как абстрактный (директива abstract ), вынуждая наследников класса создавать свою реализацию метода в обязательном порядке. Всё это — базовые вещи, которые знают все Delphi программисты. В зависимости от реализации (и документации!) базового класса, класс-наследник может решить вызывать унаследованный метод в самом начале, перед выполнением своих действий, либо в середине (довольно редко), либо после своих действий, в конце, либо же не вызывать вовсе. Существует два способа вызова унаследованного варианта метода, с тонкими отличиями: Этот код безусловно вызовет унаследованный метод Draw базового класса. Если метод в базовом классе — абстрактный, то этот вызов завершиться неудачей, возбуждая исключение EAbstractError во время выполнения (или Run-Time ошибку 210, если вы не используете исключения).

    Альтернативный синтаксис вызова — просто написать inherited; , например: Этот код будет работать идентично предыдущему для случаев, когда базовый класс содержит не абстрактный метод. Этот код также автоматически создаётся средством автодополнения кода, когда вы реализуете замещение метода (override). Кроме того, он же используется IDE, при вставке обработчиков событий форм с визуальным наследованием.

    Если же метод базового класса является абстрактным, либо же базовый класс вообще не содержит метода (для не виртуальных методов), то вызов inherited становится noop (No-Operation — пустым оператором). Компилятор не генерирует для него кода (и поэтому вы не можете поставить на него точку останова). Этот механизм является частью отличной версионной устойчивости языка Delphi.

    Один подводный камень с синтаксисом inherited; — он не поддерживается для функций. Для функций вам нужно использовать явный синтаксис с указанием имени метода и его аргументов. К примеру: Это может выглядеть как чрезмерное ограничение дизайна языка Delphi, но я думаю, что это не случайно. Смысл этого, вероятно, в том, что если TMyClass.MethodC является абстрактным (или будет сделан абстрактным в будущем), то присваивание результата вызова в Result в классе-потомке будет удалено, что приведёт к неожиданному неопределенному значению. Это, конечно же, приведёт к скрытым багам в коде.

    Однако, я думаю, что здесь есть небольшой пробел в синтаксисе унаследованного вызова. Во многих отношениях процедура, которая принимает out параметры (а в некоторых случаях и var параметры), ведёт себя как функция, возвращающая результат. Так, на мой взгляд, синтаксис inherited; должен быть запрещён при вызове методов с out (и, возможно, var ) параметрами. Сейчас это не так. Этот код означает, что если метод родительского класса является абстрактным (или просто отсутствует в случае не виртуального метода), то значение выходного параметра будет неопределённым. На мой взгляд, компилятор должен запрещать такие вызовы inherited; , требуя явного синтаксиса inherited MethodB(A); Но кота уже выпустили из мешка и уже слишком поздно что-то менять — блокировка подобных вызовов с ошибкой компиляции определённо поломает кучу кода, так что, вероятно, это тянет максимум на предупреждение (warning).

    Программирование на языке Delphi. Глава 5. Динамически загружаемые библиотеки. Часть 1

    Оглавление

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

    Динамически загружаемые библиотеки

    Динамически загружаемая библиотека (от англ. dynamically loadable library) — это библиотека подпрограмм, которая загружается в оперативную память и подключается к использующей программе во время ее работы (а не во время компиляции и сборки). Файлы динамически загружаемых библиотек в среде Windows обычно имеют расширение .dll (от англ. Dynamic-Link Library). Для краткости в этой главе мы будем использовать термин динамическая библиотека, или даже просто библиотека, подразумевая DLL-библиотеку.

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

    Одно из важнейших назначений динамически загружаемых библиотек — это взаимодействие подпрограмм, написанных на разных языках программирования. Например, вы можете свободно использовать в среде Delphi динамически загружаемые библиотеки, разработанные в других системах программирования с помощью языков C и C++. Справедливо и обратное утверждение — динамически загружаемые библиотеки, созданные в среде Delphi, можно подключать к программам на других языках программирования.

    Разработка библиотеки


    Структура библиотеки

    По структуре исходный текст библиотеки похож на исходный текст программы, за исключением того, что текст библиотеки начинается с ключевого слова library , а не слова program . Например:

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

    Если в теле библиотеки объявлены некоторые процедуры,

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

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

    Ниже приведен пример исходного текста простейшей динамически загружаемой библиотеки SortLib. Она содержит единственную процедуру BubleSort, сортирующую массив целых чисел методом «пузырька»:

    Исходный текст динамически загружаемой библиотеки заканчивается операторным блоком begin. end , в который можно вставить любые операторы для подготовки библиотеки к работе. Эти операторы выполняются во время загрузки библиотеки основной программой. Наша простейшая библиотека SortLib не требует никакой подготовки к работе, поэтому ее операторный блок пустой.

    Экспорт подпрограмм

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

    В стандартном случае экспортное имя подпрограммы считается в точности таким, как ее идентификатор в исходном тексте библиотеки (с учетом заглавных и строчных букв). Например, если секция exports имеет следующий вид,

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

    В итоге, экспортное имя процедуры BubleSort будет ’BubleSortIntegers’.

    Экспортные имена подпрограмм должны быть уникальны в пределах библиотеки, поэтому их нужно всегда указывать явно для перегруженных ( overload ) процедур и функций. Например, если имеются две перегруженные процедуры с общим именем QuickSort,

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

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

    Соглашения о вызове подпрограмм

    В главе 2 мы уже кратко рассказывали о том, что в различных языках программирования используются различные правила вызова подпрограмм, и что для совместимости с ними в языке Delphi существуют директивы register, stdcall, pascal и cdecl. Применение этих директив становится особенно актуальным при разработке динамически загружаемых библиотек, которые используются в программах, написанных на других языках программирования.

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

    Стек — это область памяти, в которую данные помещаются в прямом порядке, а и извлекаются в обратном, по аналогии с наполнением и опустошением магазина патронов у стрелкового оружия. Очередность работы с элементами в стеке обозначается термином LIFO (от англ. Last In, First Out — последним вошел, первым вышел).

    Существует еще обычная очередность работы с элементами, обозначаемая термином FIFO (от англ. First In, First Out — первым вошел, первым вышел).

    Для каждой программы на время работы создается свой стек. Через него передаются параметры подпрограмм и в нем же сохраняются адреса возврата из этих подпрограмм. Именно благодаря стеку подпрограммы могут вызывать друг друга, или даже рекурсивно сами себя.

    Вызов подпрограммы состоит из «заталкивания» в стек всех аргументов и адреса следующей команды (для воврата к ней), а затем передачи управления на начало подпрограммы. По окончании работы подпрограммы из стека извлекается адрес воврата с передачей управления на этот адрес; одновременно с этим из стека выталкиваются аргументы. Происходит так называемая очистка стека. Это общая схема работы и у нее бывают разные реализации. В частности, аргументы могут помещаться в стек либо в прямом порядке (слева направо, как они перечислены в описании подпрограммы), либо в обратном порядке (справа налево), либо вообще, не через стек, а через свободные регистры процессора для повышения скорости работы. Кроме того, очистку стека может выполнять либо вызываемая подпрограмма, либо вызывающая программа. Выбор конкретного соглашения о вызове обеспечивают директивы register, pascal, cdecl и stdcall . Их смысл поясняет таблица 1.

    Порядок занесения аргументов в стек

    Кто отвечает за очистку стека

    Передача аргументов через регистры

    register Слева направо Подпрограмма Да
    pascal Слева направо Подпрограмма Нет
    cdecl Справа налево Вызывающая программа Нет
    stdcall Справа налево Подпрограмма Нет

    Таблица 1. Соглашения о вызове подпрограмм

    Директива register не означает, что все аргументы обязательно передаются через регистры процессора. Если число аргументов больше числа свободных регистров, то часть аргументов передается через стек.

    Возникает резонный вопрос: какое соглашение о вызове следует выбирать для процедур и функций динамически загружаемых библиотек. Ответ — соглашение stdcall :

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

    Пример библиотеки

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

    Шаг 1. Запустите систему Delphi и выберите в меню команду File / New / Other. . В диалоговом окне, которое откроется на экране, выберите значок с подписью DLL Wizard и нажмите кнопку OK (рисунок 1):

    Рисунок 1. Окно выбора нового проекта, в котором выделен пункт DLL Wizard

    Среда Delphi создаст новый проект со следующей заготовкой библиотеки:

    Шаг 2. С помощью команды File / New / Unit создайте в проекте новый программный модуль. Его заготовка будет выглядеть следующим образом:

    Шаг 3. Сохраните модуль под именем SortUtils.pas, а проект — под именем SortLib.dpr. Прейдите к главному файлу проекта и удалите из секции uses модули SysUtils и Classes (они сейчас не нужны). Главный программный модуль должен стать следующим:

    Шаг 4. Наберите исходный текст модуля SortUtils:

    В этом модуле процедуры BubleSort и QuickSort сортируют массив чисел двумя способами: методом «пузырька» и методом «быстрой» сортировки соответственно. С их реализацией мы предоставляем вам разобраться самостоятельно, а нас сейчас интересует правильное оформление процедур для их экспорта из библиотеки.

    Директива stdcall , использованная при объявлении процедур BubleSort и QuickSort,

    позволяет вызывать процедуры не только из программ на языке Delphi, но и из программ на языках C/C++ (далее мы покажем, как это сделать).

    Благодаря присутствию в модуле секции exports ,

    подключение модуля в главном файле библиотеки автоматически приводит к экспорту процедур.

    Шаг 5. Сохраните все файлы проекта и выполните компиляцию. В результате вы получите на диске в своем рабочем каталоге двоичный файл библиотеки SortLib.dll. Соответствующее расширение назначается файлу автоматически, но если вы желаете, чтобы компилятор назначал другое расширение, воспользуйтесь командой меню Project / Options… и в появившемся окне Project Options на вкладке Application впишите расширение файла в поле Target file extension (рисунок 2).

    Рисунок 2. Окно настройки параметров проекта

    Кстати, с помощью полей LIB Prefix , LIB Suffix и LIB Version этого окна вы можете задать правило формирования имени файла, который получается при сборке библиотеки. Имя файла составляется по формуле:

    Илон Маск рекомендует:  Объект textrange
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL