Связь между библиотеками

Question

Мне нужно разработать интерфейсный интерфейс C ++ с использованием MSVC, который должен взаимодействовать с банковской библиотекой, скомпилированной с C ++ Builder.

Как мы можем определить наши интерфейсы, чтобы не сталкиваться с проблемами библиотеки CRT?

Например, я считаю, что мы не сможем безопасно пропустить контейнеры STL туда-сюда. Это правда?

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

Answer 1

Эта статья может показаться вам интересной Бинарно-совместимые интерфейсы C ++ .Урок, как правило, заключается в том, чтобы никогда не пропускать контейнер STL, Boost или что-либо подобное.Как и два других ответа, лучше всего придерживаться POD и функций с указанным соглашением о вызовах.

Поскольку реализации STL варьируются от компилятора к компилятору, передавать классы STL небезопасно.Затем вы можете либо потребовать от пользователя конкретной реализации STL (и, возможно, также конкретной версии), либо просто не использовать STL между библиотеками.

Более подробно придерживайтесь соглашений о вызовах, где поведение можетсчитать кросс-компилятор по-дружески.Например, __cdecl и __stdcall будут обрабатываться одинаково на большинстве компиляторов, тогда как соглашение о вызовах __fastcall будет проблемой, особенно если вы хотите использовать код в C ++ Builder.

Как статья« Бинарно-совместимый интерфейс C ++ » упоминает, что вы также можете использовать интерфейс, если вы помните несколько основных принципов.

1. Всегда делайте интерфейсы чисто виртуальными классами (т.е. без реализаций).
2. Убедитесь, что используется правильное соглашение о вызовах для функций-членов в интерфейсе (в статье упоминается __stdcallдля Windows.
3. Держите память в чистоте по ту же сторону от границы DLL.
4. И многие другие вещи, например, не используйте исключения, не перегружайте функции винтерфейс (компиляторы относятся к этому по-разному) и т. д. Найдите их все в нижней части статьи.

Возможно, вы захотите прочитать больше о объектной модели компонентов (COM), если решите использоватьИнтерфейсы C ++, чтобы получить представление о том, как и почему это будет работать в разных компиляторах.

Answer 2

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

Вы, вероятно, сможете передавать структуры POD, если будете очень осторожны с размещением их в памяти и убедитесь, что оба компилятора используют одинаковую упаковку данных и т. Д. Помимо структур C у вас в значительной степени есть проблема ручья / весла.

Для передачи более сложных типов данных я хотел бы рассмотреть такие технологии объектных компонентов, как COM, CORBA или другие, которые позволяют выполнять удаленные или межпроцессные вызовы функций. Это решит проблему распределения данных между компиляторами и процессами и, таким образом, решит вашу проблему «только для модуля».

Или вы можете написать интерфейс, используя C ++ - Builder, и избавить себя от множества горя и головной боли.

Answer 3

Я столкнулся с проблемами при передаче STL-контейнеров даже при использовании одной и той же STL-реализации, но с установкой разных уровней отладочной информации и т. Д. Поэтому передача POD будет в порядке. Контейнеры C ++ почти наверняка приведут к проблемам.