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

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

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

1) Use only basic C++ types

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

void my_func(double my_quat[4])

2) Expose Eigen's Types

Eigen предоставляет несколько шаблонных типов для массивов и кватернионов. За Например, если функция требует кватерниона, я мог бы использовать Eigen 'sQuaterniond тип (который на самом деле является typedef дляQuaternion<double>):

void my_func(const Eigen::Quaterniond& my_quat)

3) Create a simple wrapper for the various types for clients

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

void my_func(const quaternion_t& my_quat)

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

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

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

Related Questions

Был задан связанный вопросВот но на самом деле не вдавались в подробности того,should выставлять внешние типы.

Ответы на вопрос(2)

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

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

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

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

Решение Вопроса

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

Ваш ответ на вопрос