Может ли двоичный код C ++ стать переносимым через собственный интерфейс C? Каковы ограничения?

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

Из моего чтения здесь и там я понимаю, что единственное требование, чтобы это работало, это наличие интерфейсов функций использовать только нативные типы или структуры этих типов. (так, int а также longs, float, doubleи т. д. и их указатели любого ранга).

Мой вопрос: при условии полного Совместимость с ABI между различными компиляторами, это единственное требование, которое я должен выполнить, чтобы иметь полную совместимость API с общей библиотекой?

Почему библиотеки C ++ нельзя портировать? Вот мое понимание:

Случай 1: Рассмотрим тип std::string, Внутренне он содержит char* строка с нулевым символом в конце и целое число размера. Стандарт C ++ не говорит, какой из них должен стоять первым (верно?). Это значит, что если я поставлю std::string на интерфейсе функций два разных компилятора могут иметь их в разном порядке, что не будет работать.

Случай 2: Рассмотрим наследование и vtables для класса с виртуальными методами. Стандарт C ++ не требует какой-либо конкретной позиции / порядка для того, куда должны идти указатели vtable (верно?). Они могут находиться в начале класса перед любой другой переменной, а также в конце после всех других переменных-членов. Итак, еще раз, взаимодействие этого класса с функцией не будет согласованным.

Дополнительный вопрос после моего первого: Разве эта проблема не возникает и внутри вызовов функций? Или это ничего не значит после того, как он скомпилирован в двоичный файл, а типы больше не имеют значения? Не вызовут ли элементы RTTI проблемы, например, если я помещу их в интерфейс оболочки C?