Определение клиентской совместимости

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

Некоторые изменения незначительны; они включают добавляющие символы, которые неизвестны клиентам. Другие изменения являются главными; такие изменения включают удаление символа, изменение размера или видимости символа и изменения семантики функции. Все символы, которые библиотека представляет клиентам, составляют ABI библиотеки (двоичный интерфейс приложения). API библиотеки (интерфейс программирования приложения) включает только функции, которые библиотека делает доступным для ее клиентов. Градус, до которого ABI библиотеки остается тем же с точки зрения клиентов, разработанных с помощью более ранней версии библиотеки, определяет устойчивость библиотеки. Обеспечение, что ABI библиотеки остается стабильными гарантиями, что клиенты могут использовать более новые версии неизменной библиотеки. Т.е. пользователи приложения, зависящего от библиотеки, это обновляется регулярно, видят, что производительность их приложения улучшается, поскольку они обновляют библиотеку (думайте о механизме Обновления программного обеспечения OS X), не получая новую версию приложения.

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

Рисунок 1 иллюстрирует жизненный цикл Получения динамическая библиотека и один из ее клиентов.

Этот список описывает версии библиотеки и клиента:

• Нарисуйте 1.0, начальная версия библиотеки. Это экспортирует две функции, draw_line и draw_square.

• Клиент 1.0 соединяется с Получением 1.0. Поэтому это может использовать эти два символа экспорт библиотеки.

• Нарисуйте 1.1, имеет более быстрые версии draw_line и draw_square , но их семантика неизменна, поддерживая клиентскую совместимость. Это - совместимая, незначительная версия, потому что Клиент 1.0 может использовать, Рисуют 1.1.

• Нарисуйте 1.2, представляет draw_polygon функция. API новой версии библиотеки является надмножеством API предыдущей версии. Получение 1,1 подмножества API 1,2 версий неизменно. Поэтому Клиент 1.0 может использовать, Рисуют 1.2. Однако Клиент 1.0 не знает о существовании draw_polygon и, поэтому, это не использует его. Это - незначительная версия, потому что Клиент API 1.0 знает о, неизменно в Получении 1.2. Но это - также несовместимая версия, потому что изменился API. Клиенты, соединенные с этой версией библиотеки, не могут использовать более ранние версии.

• Клиент 1.1 соединяется с Получением 1.2 и использование draw_polygon. Клиент 1.1 не может использовать более ранние версии библиотеки, потому что она использует draw_polygon, функция, не экспортирующаяся теми версиями. Однако, если разработчик библиотеки добавляет weak_import припишите определению символа, Клиент 1.1 был бы в состоянии использовать более ранние версии библиотеки путем обеспечения этого draw_polygon существует в его пространстве имен перед использованием его. Если символ не определяется, клиент может использовать другие средние значения выполнения желаемой задачи, или это может не выполнить задачу. Посмотрите, что Символ Экспортирует Стратегии подробных данных.

• Нарисуйте 2.0, не экспортирует draw_square. Это - главная версия, потому что символ, экспортируемый в предыдущей версии библиотеки, не экспортируется в этой версии. Клиенты, соединенные с этой версией библиотеки, не могут использовать более ранние версии.

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

Указание информации о версии

Имя файла динамической библиотеки обычно содержит имя библиотеки с lib префикс и .dylib расширение. Например, библиотека под названием Динамо имела бы имя файла libDynamo.dylib. Однако, если библиотека может пройти через одну или более версий после того, как она выпущена, ее имя файла должно включать номер основной версии версии. Клиенты соединились с библиотеками, имя файла которых включает номер основной версии версии, никогда не используют новую главную версию библиотеки, потому что главные версии публикуются под различными именами файлов. Эта модель управления версиями препятствует тому, чтобы клиенты использовали версии библиотеки, API которых является несовместимым с API, известным клиентам.

То, когда Вы публикуете динамическую библиотеку, намеревалось иметь будущие версии, необходимо раскрыть номер основной версии библиотеки в его имени файла. Например, имя файла для первой версии библиотеки Draw, представленной в Определении Клиентской Совместимости, могло быть libDraw.A.dylib. Буква A указывает номер основной версии для первоначальной версии. Можно использовать любую номенклатуру для основной версии. Например, библиотеку Draw можно было также назвать libDraw.1.dylib, или libDraw.I.dylib. Важная вещь состоит в том, что имена файлов последующих главных версий библиотеки имеют отличающийся (и предпочтительно инкрементный) номера основной версии. Продолжая пример библиотеки Draw, главную версию к библиотеке можно было назвать libDraw.B.dylib , libDraw.2.dylib, или libDraw.II.dylib. Незначительные версии библиотеки выпущены под тем же именем файла, используемым предыдущей главной версией.

В дополнение к номеру основной версии библиотека имеет номер вспомогательной версии. Номер вспомогательной версии является инкрементным числом с помощью формата X[.Y[.Z]] , где X число между 0 и 65535, и Y и Z являются числами между 0 и 255. Например, номер вспомогательной версии для первого выпуска библиотеки Draw мог быть 1.0. Для установки номера вспомогательной версии динамической библиотеки используйте clang -current_version <version_number> опция.

Число версии совместимости подобно номеру вспомогательной версии; это установлено через компилятор -compatibility_version параметр командной строки. Число версии совместимости выпуска библиотеки указывает, что самая ранняя вспомогательная версия клиентов, соединенных с тем выпуском, может использовать. Например, пример в Определении Клиентской Совместимости указывает, что Клиент 1.1 не может использовать версии библиотеки Draw ранее, чем 1,2, потому что они не экспортируют draw_polygon функция. Для просмотра текущих версий библиотеки и версий совместимости используйте otool -L <library> команда.

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

Решение, что символы экспортировать

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

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

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

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

Именование экспортируемых символов

Динамический загрузчик не обнаруживает конфликты имен между символами, экспортируемыми динамическими библиотеками, которые он загружает. Когда клиент содержит ссылку на символ, что два или больше из его экспорта зависимых библиотек, динамический загрузчик связывает ссылку на первую зависимую библиотеку, экспортирующую символ в списке зависимой библиотеки клиента. Список зависимой библиотеки является списком зависимых библиотек клиента в порядке, они были указаны, когда клиент был соединен с ними. Кроме того, когда dlsym(3) OS X Developer Tools Manual Page функция вызывается, динамический загрузчик возвращает адрес первого символа, который это находит в указанном объеме (глобальная переменная, локальная, или затем) с соответствующим именем. Для получения дополнительной информации на поисковом символом объеме, посмотрите Используя Символы.

Чтобы гарантировать, чтобы у клиентов Вашей библиотеки всегда был доступ к символам Ваш экспорт библиотеки, символы должны иметь уникальные имена в пространстве имен процесса. Один путь для приложений для использования двухуровневых пространств имен. Другой должен добавить префиксы к каждому экспортируемому символу. Это - соглашение, используемое большинством платформ OS X, таких как Углерод и Какао. Для получения дополнительной информации о двухуровневом пространстве имен посмотрите Выполняющиеся Мужественные Файлы в Мужественных Темах Программирования.

Стратегии экспорта символа

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

• static класс памяти: Это - самый простой способ указать, что Вы не хотите экспортировать символ.

• Экспортируемый список символов или неэкспортируемый список символов: список является файлом с именами символов для экспорта или список символов для хранения частным. Имена символа должны включать подчеркивание (_) префикс. Можно использовать только один тип списка при генерации динамического файла библиотеки.

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

• Компилятор -fvisibility параметр командной строки: Эта опция указывает во время компиляции видимость символов с неуказанной видимостью в файлах реализации. Эта опция, объединенная с visibility припишите, самый безопасный и удобный способ идентифицировать общедоступные символы.

• weak_import атрибут: Размещение этого атрибута в объявлении символа в заголовочном файле говорит компилятору генерировать слабую ссылку на символ. Эту функцию вызывают слабым соединением; символы с weak_import атрибут вызывают слабо соединенными символами. Когда версия зависимой библиотеки, найденной во время запуска или время загрузки, не экспортирует слабо соединенный символ, на который ссылается клиент, со слабым соединением запускаются клиенты. Важно поместить weak_import атрибут в заголовочных файлах, что исходные файлы клиентского использования библиотеки, так, чтобы разработчики клиента знали, что они должны гарантировать существование символа перед использованием его. Иначе, клиент отказал бы или функционировал бы неправильно, когда это пытается использовать символ. Посмотрите Используя Слабо Соединенные Символы для получения дальнейшей информации на слабо соединенных символах. Для получения дополнительной информации об определениях символа посмотрите Выполняющиеся Мужественные Файлы в Мужественных Темах Программирования.

• Компилятор -weak_library параметр командной строки: Эта опция говорит компилятору обрабатывать экспортируемые символы всей библиотеки как слабо соединенные символы.

Чтобы проиллюстрировать, как установить видимость символов библиотеки, давайте запустимся с динамической библиотеки, позволяющей ее клиентам устанавливать значение, сохраненное в глобальной переменной в библиотеке и получать значение. Перечисление 1 показывает код, составляющий библиотеку.

Перечисление 1  простая динамическая библиотека

/* File: Person.h */

char* name(void);

void set_name(char* name);

/* File: Person.c */

#include "Person.h"

#include <string.h>

char _person_name[30] = {'\0'};

char* name(void) {

    return _person_name;

}

void _set_name(char* name) {

   strcpy(_person_name, name);

}

void set_name(char* name) {

    if (name == NULL) {

        _set_name("");

    }

    else {

        _set_name(name);

    }

}

Намерение разработчика библиотеки состоит в том, чтобы предоставить клиентам возможность установить значение _person_name с set_name функционируйте и позволять им получить значение переменной с name функция. Однако библиотека экспортирует больше, чем name и set_name функции, как показано выводом nm инструмент командной строки:

% clang -dynamiclib Person.c -o libPerson.dylib

% nm -gm libPerson.dylib

                 (undefined) external ___strcpy_chk (from libSystem)

0000000000001020 (__DATA,__common) external __person_name     // Inadvertently exported

0000000000000e80 (__TEXT,__text) external __set_name          // Inadvertently exported

0000000000000e70 (__TEXT,__text) external _name

0000000000000ec0 (__TEXT,__text) external _set_name

                 (undefined) external dyld_stub_binder (from libSystem)

Обратите внимание на то, что _person_name глобальная переменная и _set_name функция экспортируется вместе с name и set_name функции. Существует много опций удалить _person_name и _set_name от символов, экспортируемых библиотекой. Этот раздел исследует некоторых.

Право преимущественной покупки должно добавить статический класс памяти к определению _person_name и _set_name в Person.c , как показано в Перечислении 2.

  Модуль Лица перечисления 2, скрывающий символ со статическим классом памяти

/* File: Person.c */

#include "Person.h"

#include <string.h>

static char _person_name[30] = {'\0'};        // Added 'static' storage class

char* name(void) {

    return _person_name;

}

static void _set_name(char* name) {           // Added 'static' storage class

   strcpy(_person_name, name);

}

void set_name(char* name) {

    if (name == NULL) {

        _set_name("");

    }

    else {

        _set_name(name);

    }

}

Теперь, nm вывод, похож на это:

                 (undefined) external ___strcpy_chk (from libSystem)

0000000000000e80 (__TEXT,__text) external _name

0000000000000e90 (__TEXT,__text) external _set_name

                 (undefined) external dyld_stub_binder (from libSystem)

Это означает, что библиотека экспортирует только name и set_name. Фактически, библиотека также экспортирует некоторые неопределенные символы, включая strcpy. Они - ссылки на символы, которые библиотека получает из ее зависимых библиотек.

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

Вторая опция для представления только символы, предназначенные для клиентского использования, должны иметь экспортируемый файл символов, перечисляющий символы для экспорта; все другие символы скрыты. Перечисление 3 показывает export_list файл.

  Файл перечисления 3, перечисляющий имена символов для экспорта

# File: export_list

_name

_set_name

Для компиляции библиотеки Вы используете clang -exported_symbols_list опция указать файл, содержащий имена символов для экспорта, как показано сюда:

clang -dynamiclib Person.c -exported_symbols_list export_list -o libPerson.dylib

Третья и самая удобная опция для представления только name и set_name должен установить атрибут видимости в их реализациях к "default" и набор -fvisibility параметр командной строки компилятора к скрытому при компиляции исходных файлов библиотеки. Перечисление 4 показывает как Person.c файл заботится об установке visibility атрибут для символов, которые будут экспортироваться.

  Модуль Лица перечисления 4 с помощью видимости приписывает символам экспорта

/* File: Person.c */

#include "Person.h"

#include <string.h>

// Symbolic name for visibility("default") attribute.

#define EXPORT __attribute__((visibility("default")))

char _person_name[30] = {'\0'};

EXPORT                        // Symbol to export

char* name(void) {

    return _person_name;

}

void _set_name(char* name) {

   strcpy(_person_name, name);

}

EXPORT                        // Symbol to export

void set_name(char* name) {

    if (name == NULL) {

        _set_name("");

    }

    else {

        _set_name(name);

    }

}

Библиотека была бы тогда скомпилирована с помощью следующей команды:

% clang -dynamiclib Person.c -fvisibility=hidden -o libPerson.dylib

-fvisibility=hidden параметр командной строки говорит, что компилятор для установки видимости любых символов без видимости приписывает скрытому, таким образом скрывая их от клиентов библиотеки. Для получения дополнительной информации на visibility атрибут и -fvisibility параметр командной строки, посмотрите http://gcc .gnu.org/onlinedocs/gcc и clang страница справочника.

После этих экспортирующих символ инструкций гарантирует, чтобы библиотеки экспортировали только символы, которые Вы хотите сделать доступным для Ваших клиентов, упрощая использование библиотеки ее клиентами и упрощая ее обслуживание его разработчиками. Документ, Как Записать Совместно используемые Библиотеки, обеспечивает глубокий анализ стратегий экспорта символа. Этот документ доступен в http://people .redhat.com/drepper/dsohowto.pdf.

Экспорт символов C++

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

Для экспорта символов лица, не являющегося членом какой-либо организации, из основанной на С++ динамической библиотеки так, чтобы динамический загрузчик мог найти его необходимо добавить extern "C" директива к объявлениям символов. Это ключевое слово говорит компилятору не искажать имя символа. Например, следующее объявление делает NewPerson функционируйте доступные клиентам библиотеки:

extern "C" Person* NewPerson(void);

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

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

Определение интерфейсов класса C++

Динамическая библиотека должна всегда публиковать свой открытый интерфейс клиентам через заголовочные файлы. (Несмотря на то, что клиенты могут пользоваться динамическими библиотеками без своих заголовочных файлов, делание так является очень трудным и является подверженным ошибке.) Заголовочный файл для класса, это доступно клиентам, должен включать объявления своих открытых методов. Динамические библиотеки, делающие класс доступным для его клиентов, должны включать виртуальное ключевое слово в объявление методов всего класса, за исключением его конструкторов и деструкторов. Например, Перечисление 9 показывает объявление для класса Лица.

  Объявление перечисления 9 для класса Лица

class Person {

    private:

        char _person_name[30];

    public:

        Person();

        virtual void set_name(char person_name[]);

        virtual char* name();

};

Создание и уничтожение объектов C++

Когда основанная на С++ динамическая библиотека является зависимой библиотекой своего клиента, клиент может использовать new и delete операторы, чтобы создать и уничтожить экземпляры класса библиотека определяют. Однако клиенты, открывающие C ++-based library во время выполнения через dlopen(3) OS X Developer Tools Manual Page не имейте доступа к конструкторам библиотеки, потому что конструкторы экспортируются с их искаженными именами, препятствуя тому, чтобы динамический загрузчик определил местоположение их. См. Перечисление 11 для подробных данных об искажении имени.

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

Например, Перечисление 10 показывает заголовок и файлы реализации Person класс, экспортируемый библиотекой Person. Заголовочный файл включает объявление и определение типа пары функций фабрики, NewPerson, и DeletePerson:

  Интерфейс перечисления 10 и реализация класса C++ в динамической библиотеке

/* File: Person.h */

class Person {

    private:

        char _person_name[30];

    public:

        Person();

        virtual void set_name(char person_name[]);

        virtual char* name();

};

// Constructor function and function type.

extern "C" Person *NewPerson(void);

typedef Person *Person_creator(void);

// Destructor function and function type.

extern "C" void DeletePerson(Person *person);

typedef void Person_disposer(Person *);

/* File: Person.cpp */

include <iostream>

#include "Person.h"

#define EXPORT __attribute__((visibility("default")))

EXPORT

Person::Person() {

    char default_name[] = "<no value>";

    this->set_name(default_name);

}

EXPORT

Person* NewPerson(void) {

    return new Person;

}

EXPORT

void DeletePerson(Person* person) {

    delete person;

}

void Person::set_name(char name[]) {

    strcpy(_person_name, name);

}

char* Person::name(void) {

    return _person_name;

}

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

  Клиент перечисления 11, использующий класс C++, реализован в загруженной временем выполнения библиотеке

/* File: Client.cpp */

#include <iostream>

#include <dlfcn.h>

#include "Person.h"

int main() {

    using std::cout;

    using std::cerr;

    // Open the library.

    void* lib_handle = dlopen("./libPerson.dylib", RTLD_LOCAL);

    if (!lib_handle) {

        cerr << "[" << __FILE__ << "] main: Unable to open library: "

             << dlerror() << "\n";

        exit(EXIT_FAILURE);

    }

    // Get the NewPerson function.

    Person_creator* NewPerson = (Person_creator*)dlsym(lib_handle, "NewPerson");

    if (!NewPerson) {

        cerr << "[" << __FILE__ << "] main: Unable to find NewPerson method: "

             << dlerror() << "\n";

        exit(EXIT_FAILURE);

    }

    // Get the DeletePerson function.

    Person_disposer* DeletePerson =

        (Person_disposer*)dlsym(lib_handle, "DeletePerson");

    if (!DeletePerson) {

        cerr << "[" << __FILE__

             << "] main: Unable to find DeletePerson method: "

             << dlerror() << "\n";

        exit(EXIT_FAILURE);

    }

    // Create Person object.

    Person* person = (Person*)NewPerson();

    // Use Person object.

    cout << "[" << __FILE__ << "] person->name() = " << person->name() << "\n";

    char new_name[] = "Floriane";

    person->set_name(new_name);

    cout << "[" << __FILE__ << "] person->name() = " << person->name() << "\n";

    // Destroy Person object.

    DeletePerson(person);

    // Close the library.

    if (dlclose(lib_handle) != 0) {

        cerr << "[" << __FILE__ << "] main: Unable to close library: "

             << dlerror() << "\n";

    }

    return 0;

}

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

% clang++ -dynamiclib Person.cpp -fvisibility=hidden -o libPerson.dylib

% clang++ Client.cpp -o client

Для получения дальнейшей информации о том, как клиенты используют классы C++, реализованные в динамических библиотеках, посмотрите Используя Классы C++.

Определение интерфейсов класса и категории

Поскольку у разработчиков клиента обычно нет доступа к реализации классов Objective C и категорий определенным в динамических библиотеках, разработчики библиотеки должны опубликовать открытые интерфейсы классов и категорий как протоколы в заголовочных файлах. Разработчики клиента компилируют свои продукты с помощью тех заголовочных файлов и в состоянии инстанцировать классов правильно путем добавления необходимых имен протокола к определениям переменной. Перечисление 12 показывает заголовок и файлы реализации Person класс в библиотеке Objective-C–based. Перечисление 13 показывает заголовок и файлы реализации Titling категория в той же библиотеке, добавляющей -setTitle метод к Person класс.

  Заголовок перечисления 12 и файлы реализации Person класс

/* File: Person.h */

#import <Foundation/Foundation.h>

@protocol Person

- (void)setName:(NSString*)name;

- (NSString*)name;

@end

@interface Person : NSObject <Person> {

    @private

    NSString* _person_name;

}

@end

/* File: Person.m */

#import <Foundation/Foundation.h>

#import "Person.h"

@implementation Person

- (id)init {

    if (self = [super init]) {

        _person_name = @"";

    }

    return self;

}

- (void)setName:(NSString*)name {

    _person_name = name;

}

- (NSString*)name {

    return _person_name;

}

@end

  Заголовок перечисления 13 и файлы реализации Titling категория к Person класс

/* File: Titling.h */

#import <Foundation/Foundation.h>

#import "Person.h"

@protocol Titling

- (void)setTitle:(NSString*)title;

@end

@interface Person (Titling) <Titling>

@end

/* File: Titling.m */

#import <Foundation/Foundation.h>

#import "Titling.h"

@implementation Person (Titling)

- (void)setTitle:(NSString*)title {

    [self setName:[[title stringByAppendingString:@" "]

        stringByAppendingString:[self name]]];

}

@end

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

  Клиент перечисления 14, пользующийся библиотекой Person

/* File: Client.m */

#import <Foundation/Foundation.h>

#import <objc/runtime.h>

#import <dlfcn.h>

#import "Person.h"

#import "Titling.h"

int main() {

    @autoreleasepool {

        // Open the library.

        void* lib_handle = dlopen("./libPerson.dylib", RTLD_LOCAL);

        if (!lib_handle) {

            NSLog(@"[%s] main: Unable to open library: %s\n",

            __FILE__, dlerror());

            exit(EXIT_FAILURE);

        }

        // Get the Person class (required with runtime-loaded libraries).

        Class Person_class = objc_getClass("Person");

        if (!Person_class) {

            NSLog(@"[%s] main: Unable to get Person class", __FILE__);

            exit(EXIT_FAILURE);

        }

        // Create an instance of Person.

        NSLog(@"[%s] main: Instantiating Person_class", __FILE__);

        NSObject<Person,Titling>* person = [Person_class new];

        // Use person.

        [person setName:@"Perrine LeVan"];

        [person setTitle:@"Ms."];

        NSLog(@"[%s] main: [person name] = %@", __FILE__, [person name]);

        // Close the library.

        if (dlclose(lib_handle) != 0) {

            NSLog(@"[%s] Unable to close library: %s\n",

                __FILE__, dlerror());

            exit(EXIT_FAILURE);

        }

    }

    return(EXIT_SUCCESS);

}

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

clang -framework Foundation -dynamiclib Person.m Titling.m -o libPerson.dylib

clang -framework Foundation Client.m -o client

Инициализация классов Objective C

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

1. +load метод: Инициализирует ресурсы, необходимые классу или категории. Время выполнения Objective C отправляет load обменивайтесь сообщениями к каждому классу, который реализует библиотека; это тогда отправляет load передайте к каждой категории реализации библиотеки. Порядок, в котором одноуровневые классы отправляются load сообщение является неопределенным. Реализуйте +load метод для инициализации ресурсов, необходимых классу или категории. Обратите внимание на то, что нет никакого соответствия, «разгружают» метод.

2. Инициализаторы модуля: Инициализирует модуль. Динамический загрузчик вызывает все функции инициализатора (определенный с помощью constructor атрибут) в каждом из модулей библиотеки. Посмотрите Инициализаторы Модуля и Финализаторы для получения дополнительной информации об инициализаторах модуля.

3. +initialize метод: Инициализирует ресурсы, необходимые экземплярам класса, прежде чем будут созданы любые экземпляры. Время выполнения Objective C отправляет initialize обменивайтесь сообщениями к классу прежде, чем создать экземпляр класса. Обратите внимание на то, что нет никакого соответствия, «завершают» сообщение, отправленное в класс, когда библиотека разгружена, или процесс завершается.

Создание псевдонимов к классу

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