¿Por qué debería configurar una interfaz de complemento en C++ en lugar de c

Question

Como resultado de mi previousquestions me pregunté: ¿es útil instalar una interfaz C++ para un sistema de complemento? Los siguientes puntos están hablando en contra de ella:

• Sin ABI común entre los distintos compiladores y sus versiones, sin la disposición común de los objetos en la memoria
• Sin exportación de clase directa. Tienes que exportar fábricas y destructores. Se producen problemas si sus objetos están en manos de otros objetos que solo los tienen en delete, por ejemplo, punteros inteligentes.
• diferentes implementaciones de la STL, no se puede pasar un std::list<T> al plugin
• Las diferentes versiones de las bibliotecas utilizadas como Boost

Si refrenarse a las partes restantes del lenguaje C++ terminas casi con el "subconjunto C". ¿Hay algún punto hablando por usar C++? ¿Cómo resuelve Qt-Toolkit los problemas mencionados?

Observación: me refiero principalmente al sistema Linux. Sin embargo, estoy interesado en soluciones en otras plataformas.

Pregunta adicional: ¿Cuáles son los problemas al usar una interfaz C? El diseño de memoria de struct s? ¿Qué partes del lenguaje de C deberían evitarse?

Answer 1

Aunque esto se trata más del "cómo" que del "por qué", puede interesarle la biblioteca (not yet)Boost.Extension, así como también la author's blog en el tema.

Para el "por qué" parte, mis 2 (canadienses) centavos: Depende de la audiencia (los escritores de plugins) y sobre la riqueza de la interfaz entre la aplicación y sus complementos:

• Si el la audiencia es grande o heterogénea, las limitaciones de un sistema de complemento C++ (mantener el complemento y la aplicación sincronizados con respecto al compilador y las versiones de la biblioteca) se vuelven poco prácticas, y una interfaz C es más fácil de mantener. Si la audiencia es pequeña, homogénea o está bajo su control, estos problemas no son tan significativos.
• Si la interfaz es rica (agitando manualmente el significado preciso de "rico"), una interfaz C puede ser engorrosa para escribir, y la balanza se inclina en el lado C++.

Sin embargo, el primer criterio (el público) es más importante, y una interfaz C++ solo tiene sentido si el público es homogéneo y la interfaz se beneficia significativamente de las ganancias de expresividad.

Answer 2

Creo que estás respondiendo tu propia pregunta allí. No hay nada que te impida implementar una sencilla interfaz de complemento C y permitir a los escritores de plugins implementar su plugin con C++. Solo intente y aprenda de los errores cometidos por la API del complemento de Netscape ...

Answer 3

Generalmente es una buena idea escribir interfaces con algún estándar de interfaz con el que se puede contar. Es por eso que casi todos los sistemas operativos proporcionan dicha interfaz. En la mayoría de los Unix, los compiladores de C utilizan la misma convención que el sistema operativo, por lo que lo llaman la convención de llamadas de C. Windows ha llamado para este propósito.

Si intenta utilizar alguna interfaz de llamada interna del compilador, como C++, entonces será víctima de todos los problemas que ha mencionado. Incluso las actualizaciones del compilador pueden manguerarte.

Answer 4

Una vez hice en C++ la interfaz del complemento para un sistema que desarrollé y fue un gran error. Factible, pero no práctico en absoluto. Hoy, siempre haré la interfaz puramente en C, y tan simple como pueda. Los beneficios de estas elecciones son realmente significativos. Y si sus escritores de plugins quieren una API de C++, simplemente puede escribir un contenedor de C++ que llame a la interfaz de C.

Como una ventaja adicional, si sus escritores de plugins quieren una API en cualquier otro idioma, una API C siempre será más fácil de crear enlaces para.