Должны ли быть доступны сторонние типы в API моей библиотеки C++

Question

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

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

1) Используйте только основные C++ типы

Этот вариант требует от своих клиентов, чтобы передавать данные в по основным типам. Для например, для передачи в кватернион (4 элемента), можно было бы сделать:

void my_func(double my_quat[4]) 

2) Expose Типы Эйген в

Эйген предоставляет несколько калиброванных типов для массивов и кватернионов. Для Например, если функция требует кватерниона, я мог бы использовать Эйген в Quaterniond типе (который на самом деле является ЬурейиМ для Quaternion<double>):

void my_func(const Eigen::Quaterniond& my_quat) 

3) Создайте простую оболочку для различных типов для клиентов

я мог бы создать очень простой тип кватернионов (скажем, какой-то простой структуры), что клиенты должны создать (возможно, через какое-то функции фабричной) в проход к моему API:

void my_func(const quaternion_t& my_quat) 

Моя библиотека преобразует тип quaternion_t в мое внутреннее представление Eigen .

Мне не нравится вариант 1 слишком много, так как я хочу, чтобы там было более сильное чувство , набрав мои API. Вариант 2 потребует от моих клиентов также использовать Eigen, а не , чтобы упомянуть о потенциальных проблемах с совместимостью, если они используют другую версию Eigen (например, Eigen - это библиотека только для заголовков, если это имеет значение ). Это оставляет опцию 3.

Что думают люди? Я в основном ответил на свой вопрос? Есть ли какие-нибудь примеры?

Вопросы, относящиеся

Смежный вопрос был задан here, но на самом деле не вдаваться в подробности, следует ли один выставить внешние типы.

Answer 1

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

Answer 2

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

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

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

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