¿Cómo diseñar una biblioteca de C / C++ para ser utilizable en muchos lenguajes de cliente?

Mayormente correcto. La interfaz de procedimiento directo es la mejor. (que no es del todo lo mismo que C btw (**), pero lo suficientemente cerca)

I interfaz DLL mucho ( * ), tanto de código abierto y comercial, así que aquí hay algunos puntos que recuerdo de la práctica diaria, tenga en cuenta que estas son las áreas más recomendadas para la investigación, y no verdades cardinales:

• Tenga cuidado con la decoración y esquemas similares "menores" de manipulación, especialmente si se utiliza un compilador de MS. En particular, la convención stdcall a veces conduce a la generación de decoración por el bien de VB (decoración es cosas como @6 después del nombre del símbolo de función)
• No todos los compiladores pueden realmente diseñar todo tipo de estructuras:
  • así que evita abusar de los sindicatos.
  • evite el bitpacking
  • y preferiblemente empacar los registros. Aunque más lento, al menos todos los compiladores pueden acceder a los registros empaquetados afaik
• En Windows use stdcall. Este es el valor predeterminado para las DLL de Windows. Evite fastcall, no está completamente estandarizado (especialmente cómo se pasan los registros pequeños)
• Algunos consejos para facilitar la traducción automática de encabezados:
  • las macros son difíciles de autoconvertir debido a su falta de tipo. Evitarlos, utilizar funciones
  • Defina tipos separados para cada tipo de puntero, y no utilice tipos compuestos (xtype **) en declaraciones de funciones.
  • siga el mantra" definir antes de usar " tanto como sea posible, esto evitará que los usuarios que traducen encabezados los reorganicen si su idioma en general requiere definir antes de su uso, y hace que sea más fácil para los analizadores de una pasada para traducirlos. O si necesitan información de contexto para traducir automáticamente.
• No exponga más de lo necesario. Deje los tipos de manija opague si es posible. Solo causará problemas de versiones más adelante.
• No devuelve tipos estructurados como registros/estructuras o arrays como tipo de retorno de funciones.
• siempre tener una función de comprobación de versiones (más fácil de hacer una distinción).
• tenga cuidado con enum y booleano. Otros idiomas pueden tener suposiciones ligeramente diferentes. Puede usarlos, pero documente bien cómo se comportan y cuán grandes son. También piense en el futuro, y asegúrese de que las enumeraciones no se hacen más grandes si agrega algunos campos, rompa la interfaz. (por ejemplo, en Delphi/pascal por defecto los booleanos son 0 o 1, y otros valores no están definidos. Hay tipos especiales para booleanos similares a C (byte,tamaño de palabra de 16 bits o 32 bits, aunque se introdujeron originalmente para COM, no para la interfaz de C))
• prefiero stringtypes que son puntero a char + length como campo separado (COM también hace esto). Preferiblemente no tener que depender de cero terminado. Esto no es solo por razones de seguridad (desbordamiento), sino también porque es más fácil/más barato interactuar con los tipos nativos de Delphi de esa manera.
• Memoria siempre cree la API de manera que fomente una separación total de la administración de memoria. IOW no asume nada sobre la gestión de la memoria. Esto significa que todas las estructuras en su lib asignado a través de su propio administrador de memoria, y si una función le pasa una estructura, cópiela en lugar de almacenar un puntero hecho con la administración de memoria "clientes". Porque tarde o temprano llamarás accidentalmente gratis o realloc en él: -)
• (lenguaje de implementación, no interfaz), sea reacio a cambiar la máscara de excepción del coprocesador. Algunos lenguajes cambian esto como parte de la conformidad con sus estándares de manejo de errores de coma flotante(excepción).
• Siempre emparejar un callbacks con un contexto configurable por el usuario. Esto puede ser utilizado por el usuario para dar el estado de devolución de llamada sin definir variables globales. (como, por ejemplo, una instancia de objeto)
• tenga cuidado con la palabra de estado del coprocesador. Puede ser cambiado por otros y romper su código, y si lo cambia, otro código podría dejar de funcionar. La palabra de estado generalmente no se guarda / restaura como parte de las convenciones de llamada. Al menos no en la práctica.
• no utilice parámetros varargs de estilo C. No todos los idiomas permiten variable número de parámetros de forma insegura ( * ) Delphi programmer by day, un trabajo que implica interconectar una gran cantidad de hardware y, por lo tanto, traducir encabezados SDK de proveedores. Por la noche Free Pascal desarrollador, a cargo de, entre otros, los encabezados de Windows.

(**) Esto se debe a que lo que "C" significa binario todavía depende del compilador de C usado, especialmente si no hay un sistema universal ABI real. Piensa en cosas como:

• C añadiendo un prefijo de subrayado en algunos formatos binarios (a. out, ¿Coff?)
• a veces diferentes compiladores de C tienen diferentes opiniones sobre qué hacer con estructuras pequeñas pasadas por valor. Oficialmente no deberían apoyarlo en absoluto afaik, pero la mayoría lo hace.
• el embalaje de la estructura a veces varía, al igual que los detalles de las convenciones de llamada (como saltar registros enteros o no si un parámetro es registrable en un registro FPU)

===== conversiones automatizadas de encabezado = = = =

Aunque no sé beber tan bien, sé y uso algunos delphi herramientas de cabecera específicas (h2pas, Darth / headconv, etc.).

Sin embargo, nunca los uso en modo completamente automático, ya que más a menudo que no la salida apesta. Los comentarios cambian de línea o se eliminan, y el formato no se conserva.

Normalmente hago un pequeño script (en Pascal, pero puedes usar cualquier cosa con soporte de cadena decente) que divide un encabezado, y luego pruebo una herramienta en partes relativamente homogéneas (por ejemplo, solo estructuras, o solo define, etc.).

Entonces compruebo si me gusta el salida de conversión automática, y ya sea usarlo, o tratar de hacer un convertidor específico yo mismo. Dado que es para un subconjunto (como solo estructuras) a menudo es mucho más fácil que hacer un convertidor de encabezado completo. Por supuesto que depende un poco de cuál sea mi objetivo. (encabezados agradables y legibles o rápidos y sucios). En cada paso podría hacer algunas sustituciones (con sed o un editor).

El esquema más complicado que hice para las cabeceras Winapi commctrl y ActiveX/comctl. Allí combiné IDL y el encabezado C (IDL para las interfaces, que son un montón de macros no compatibles en C, el encabezado C para el resto), y logró obtener las macros escritas por alrededor del 80% (propogando las tipografías en las macros de sendmessage a la declaración de macro,con valores predeterminados razonables (wparam,lparam, lresult))

La forma semiautomática tiene la desventaja de que el orden de las declaraciones es diferente (por ejemplo, primero constantes, luego estructuras y luego declaraciones de funciones), lo que a veces hace que el mantenimiento sea un problema. Me por lo tanto, mantenga siempre los encabezados/sdk originales para comparar.

El proyecto de conversión Jedi winapi podría tener más información, tradujeron aproximadamente la mitad de los encabezados de windows a Delphi, y por lo tanto tienen una enorme experiencia.