Тонкости реализации кода библиотеки. Часть первая

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

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

Тонкости реализации кода библиотеки. Часть первая

Чем Ваш вариант отличается от решения №2, представленного в топике?

DynLib: библиотека для создания и работы с DLL

Ошибся. Правильная версия: если экспортируемые функции библиотеки не должны ВОЗВРАЩАТЬ типы, размер которых превышает размер регистра.

DynLib: библиотека для создания и работы с DLL

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

С-шный интерфейс библиотеки, реализованный через таблицы функций (псевдо VTable) реализован так, что функции в нем возвращают только указатель на экземпляр структуры ошибки:

Предположим, что библиотека экспортирует следующую функцию:

DL_LIBRARY( some_lib )
(
    ( double, sum, (double,x)(double,y,=0) )
)

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

struct some_lib_ftable
{
    error_info const* (*sum_fn) ( double x, double y, double& result );
    // служебные функции
};

Т.е. все в порядке с этой позиции.

Тонкости реализации кода библиотеки. Часть первая

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

namespace mylib
{
    using namespace mylib_v1;
}

А пользователь библиотеки сам решит вводить ли ему имена библиотеки в глобальное (или свое) пространство имен через using namespace mylib;.

Тонкости реализации кода библиотеки. Часть первая

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

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

// файл detail_class.hpp

namespace work_lib_namespace
{
    class detail_class
    {
    };
}

// файл some_class.hpp

#include "detail_class.hpp"

namespace work_lib_namespace
{
    class some_class
    {
    public:
        // интерфейс
    private:
        detail_class impl_;
    };
}

namespace lib_namespace
{
    using ::work_lib_namespace::some_class;
}

Тонкости реализации кода библиотеки. Часть первая

using namespace можно использовать для того, чтобы при написании самого кода библиотеки явно не задавать пространства имен для классов, структур (и др.) из других библиотек. Обычно не рекомендуется вставлять using namespace в заголовочные файла по определенным причинам (подробнее можно узнать, например в книге «Стандарты программирования на С++. 101 правило и рекомендации» Г. Саттера и А.Александреску [глава 59]). Этот прием позволяет не беспокоиться об этом.