Как разработать C / библиотека C++, чтобы быть применимым на многих клиентских языках? [закрытый]

В основном верно. Прямой процедурный интерфейс - лучший. (что не совсем то же самое, что C btw(**), но достаточно близко)

I интерфейс DLLs много(*), как с открытым исходным кодом, так и с коммерческим, поэтому вот некоторые моменты, которые я помню из повседневной практики, обратите внимание, что это более рекомендуемые области для исследования, а не кардинальные истины:

• Следите за декорациями и схожими "минорными" схемами манипуляций, особенно если вы используете компилятор MS. Особенно заметно, что соглашение stdcall иногда приводит к генерации декораций для ВБ (декорирование - это вещи типа @6 после имени символа функции)
• Не все компиляторы могут на самом деле компоновать всевозможные структуры:
  • так что избегайте чрезмерного использования союзов.
  • избегайте битпакинга
  • и предпочтительно упаковывайте записи для 32-битного x86. Хотя теоретически это медленнее, по крайней мере, все компиляторы могут получить доступ к упакованным записям afaik, и официальные требования к выравниванию изменились со временем с развитием архитектуры
• On Windows использовать stdcall. По умолчанию это используется для Windows DLL. Избегайте fastcall, он не полностью стандартизирован (особенно то, как передаются небольшие записи)
• Некоторые советы по упрощению автоматического перевода заголовков:
  • макросы трудно конвертировать в автоконвертеры из-за их непечатности. Избегайте их, используйте функции
  • Определите отдельные типы для каждого типа указателя и не используйте составные типы (xtype **) в объявлениях функций. Насколько это возможно, следуйте мантре "определить перед использованием", это позволит избежать пользователей, которые переводят заголовки, чтобы перестроить их, если их язык в целом требует определения перед использованием, и облегчит однопроходные парсеры для их перевода. Или если им нужна контекстная информация для автоматического перевода.
• Не выставляйте больше, чем необходимо. Если возможно, оставьте типы дескрипторов расплывчатыми. Это приведет только к проблемам с версионированием позже.
• Не возвращайте структурированные типы, такие как записи/инструкции или массивы, в качестве возвратного типа функций.
• всегда есть функция проверки версии (проще сделать различие).
• Будьте осторожны с перечислениями и булевыми. Другие языки могут иметь несколько иные предположения. Их можно использовать, но хорошо документируйте, как они ведут себя и насколько они велики. Также подумайте и убедитесь, что перечисления не станут больше, если вы добавите несколько полей, разобьёте интерфейс. (Например, в Delphi/pascal по умолчанию булеаны 0 или 1, а другие значения неопределенны. Для C-подобных булеанов существуют специальные типы (размер байта, 16 бит или 32 бит, хотя изначально они были введены для COM, а не для C-интерфейса)
• Я предпочитаю строковые типы, которые являются указателем на длину char + длину как отдельное поле (COM тоже так делает). Желательно не полагаться на нулевое завершение. Это не только по соображениям безопасности (переполнение), но и потому, что так проще/сложнее взаимодействовать с нативными типами Delphi.
• Memory всегда создает API таким образом, чтобы поощрялось полное разделение управления памятью. IOW ничего не предполагает в управлении памятью. Это означает, что все структуры в вашей библиотеке выделяются через собственный менеджер памяти, и если функция передает вам структуру, то скопируйте ее, вместо того, чтобы хранить указатель, сделанный с помощью "клиентского" управления памятью. Поскольку вы рано или поздно случайно вызовете free или realloc на ней :-)
• (язык реализации, а не интерфейс), неохотно меняйте маску исключений сопроцессора. Некоторые языки меняют это в соответствии со своими стандартами обработки ошибок с плавающей точкой(exception-).
• Всегда устанавливайте пару обратных вызовов с настраиваемым пользователем контекстом. Это может быть использовано пользователем для передачи состояния обратного вызова без определения глобальных переменных. (например, экземпляр объекта)
• будьте осторожны со словом состояния сопроцессора. Оно может быть изменено другими пользователями и сломать ваш код, а если вы его измените, то другой код может перестать работать. Слово статуса обычно не сохраняется/восстанавливается в рамках соглашений о вызове. По крайней мере, на практике
• не используют параметры varargs в стиле Си. Не все языки допускают небезопасное использование переменного количества параметров. (*) Delphi-программист изо дня в день, работа, связанная с взаимодействием с большим количеством аппаратного обеспечения и, таким образом, перевод заголовков SDK производителя. По ночам разработчик Free Pascal, отвечающий, среди прочего, заголовки Windows.

(**) Это связано с тем, что то, что означает "C", все еще зависит от используемого компилятора Си, особенно если нет реальной универсальной системы ABI. Подумайте о таких вещах, как:

• C добавление префикса подчеркивания в некоторых бинарных форматах (a.out, Coff?)
• иногда разные компиляторы Си имеют разные мнения о том, что делать с небольшими структурами, передаваемыми по значению. Официально они не должны поддерживать это вообще afaik, но большинство поддерживают.
• структурная упаковка иногда различается, так же как и детали вызова конвенций (например, пропуск целочисленные регистры или нет, если параметр регистрируется в FPU регистре)

===== автоматические преобразования заголовков ====

Хотя я не так хорошо знаю SWIG, я знаю и использую некоторые специфические для delphi заголовочные утилиты( h2pas, Darth/headconv и т.д.)

Однако я никогда не использую их в полностью автоматическом режиме, т.к. чаще всего не выходит отстойно. Комментарии меняются строкой или удаляются, и форматирование не сохраняется.

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

Затем я проверяю, нравится ли мне автоматический вывод преобразования, и либо использую его, либо пытаюсь сделать конкретный конвертер сам. Так как это для подмножества (например, только структуры), то часто это намного проще, чем сделать полный конвертер заголовков. Конечно, это немного зависит от того, что моя цель. (красивые, читаемые заголовки или быстро и грязно). На каждом шаге я могу сделать несколько замен (с помощью sed или редактора).

Самая сложная схема, которую я делал для заголовков Winapi commctrl и ActiveX/comctl. Там я объединил IDL и заголовок C (IDL для интерфейсов, которые представляют собой кучу недоступных макросов на C, заголовок C для остальных), и умудрился набрать макросы примерно на 80% (путем возврата шрифтов в макросах sendmessage обратно к макро-декларации, с разумными (wparam, lparam, lresult) значениями по умолчанию)

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

Проект преобразования Jedi winapi может иметь больше информации, они перевели примерно половину заголовков окон в Delphi, и таким образом имеют огромный опыт.