studio - visual c++ console application

¿COM en el mundo no Windows? (4)

En el mundo de Linux, es más común desarrollar componentes que están vinculados estáticamente, o que se ejecutan en procesos separados y se comunican mediante el flujo de texto (tal vez JSON o XML) de un lado a otro.

Algo de esto se debe a la tradición. Los desarrolladores de UNIX han estado haciendo cosas como esta mucho antes de que CORBA o COM existieran. Es "la forma UNIX".

Como dice Jerry Coffin en su respuesta, cuando tienes el código fuente para todo, las interfaces binarias no son tan importantes y, de hecho, hacen que todo sea más difícil.

COM se inventó cuando las computadoras personales eran mucho más lentas de lo que son hoy. En esos días, a menudo era necesario cargar componentes en el espacio de proceso de su aplicación e invocar código nativo para lograr un rendimiento razonable. Ahora, analizar el texto y ejecutar scripts interpretados no es algo que deba temer.

CORBA nunca se puso realmente de moda en el mundo de código abierto porque las implementaciones iniciales eran propietarias y caras, y cuando las implementaciones gratuitas de alta calidad estaban disponibles, la especificación era tan complicada que nadie quería usarla si no fuera necesario. hazlo

Espero que esta pregunta no sea demasiado vaga. Al leer las especificaciones COM y el libro COM esencial de Don Box, se habla mucho de los "problemas que resuelve COM", y todos parecen importantes, relevantes y current .

Entonces, ¿cómo se solucionan los problemas que abordan los COM en otros sistemas (linux, unix, OSX, android)? Estoy pensando en cosas como:

Compatibilidad binaria entre compiladores y versiones de compilador.
reutilización de componentes binarios
compilar una aplicación de tal manera que tenga dependencias en tiempo de ejecución en lugar de dependencias en tiempo de carga (de modo que se ejecute incluso cuando falta una dependencia)
Acceso a la funcionalidad de la biblioteca desde otros idiomas distintos a los de la biblioteca.
El procedimiento remoto razonablemente bajo-sobrecarga llama a los componentes cargados en el espacio de direcciones de un proceso diferente
etc (estoy seguro de que la lista continúa)

Básicamente, solo estoy tratando de entender por qué, por ejemplo, en Linux CORBA no es algo como que COM es algo en Windows (si eso tiene sentido). ¿Es posible que el desarrollo de software en Linux se suscriba a una filosofía diferente a la del modelo basado en componentes propuesto por COM?

Y finalmente, ¿es COM una cosa C / C ++? Varias veces me he topado con comentarios de personas que dicen que COM es "obsoleto" por .NET pero sin explicar realmente lo que querían decir con eso.

En gran medida, los problemas resueltos por COM simplemente se ignoran en Linux.

Es cierto que la compatibilidad binaria es menos importante cuando tiene el código fuente disponible. Sin embargo, todavía tiene que preocuparse por la modularización y el control de versiones. Si dos programas diferentes dependen de versiones diferentes de la misma biblioteca, debe admitirlo de alguna manera.

Luego está el caso del mismo programa que usa diferentes versiones de la misma biblioteca. A menudo, esto es útil cuando se trabaja en grandes programas heredados, donde la actualización de todo puede ser prohibitivamente costosa, pero le gustaría usar nuevas características de todos modos. Con COM, las partes antiguas del programa pueden dejarse solas, ya que las nuevas versiones de la biblioteca se pueden hacer más fácilmente compatibles con versiones anteriores.

Además, tener que compilar desde el origen en lugar de la compatibilidad binaria es una gran molestia. Especialmente si realmente estás desarrollando software, ya que la incompatibilidad binaria significa que tienes que recompilar mucho más a menudo. Si una pequeña parte cambia en un programa grande de C ++, es posible que deba esperar una recompilación de 30 minutos. Si las diferentes piezas son compatibles, solo se debe volver a compilar la parte que cambió.

Por el momento, consideremos Linux.

Para Linux, los dos primeros puntos tienden a tener una relevancia relativamente baja. La mayoría del software es de código abierto, y muchos usuarios están acostumbrados a construir desde el origen en cualquier caso. Para tales usuarios, la compatibilidad / reutilización binaria tiene poca o ninguna consecuencia (de hecho, es probable que algunos usuarios rechacen todo el software que no esté distribuido en forma de código fuente).

Ser capaz de cargar y ejecutar (con capacidades reducidas) cuando falta un componente también es un problema de código cerrado. El software de código cerrado normalmente tiene varias versiones con diferentes capacidades para soportar diferentes precios. Es conveniente para el proveedor poder compilar una versión de la aplicación principal y brindar diferentes niveles de funcionalidad dependiendo de qué otros componentes se suministran / omiten.

Eso es principalmente para apoyar diferentes niveles de precios sin embargo. Cuando el software es gratuito, solo hay un precio y una versión: la edición impresionante .

El acceso a la funcionalidad de la biblioteca entre idiomas nuevamente se basa más en el código fuente que en una interfaz binaria, como el uso de SWIG para permitir el uso del código fuente C o C ++ de lenguajes como Python y Ruby. Una vez más, COM está básicamente solucionando un problema que surge principalmente de la falta de código fuente; cuando se usa software de código abierto, el problema simplemente no surge para empezar.

El RPC de bajo costo para codificar en otros procesos parece derivar principalmente del software de código cerrado. Cuando / si desea que Microsoft Excel pueda usar algunas "cosas" internas en, digamos, Adobe Photoshop, use COM para que se comuniquen. Eso agrega una sobrecarga en el tiempo de ejecución y una complejidad adicional, pero cuando uno de los fragmentos de código es propiedad de Microsoft y el otro de Adobe, es más o menos lo que está atrapado.

Sin embargo, en el software de código abierto, si el proyecto A tiene alguna funcionalidad que es útil en el proyecto B, lo que probablemente verá es (a lo sumo) una bifurcación del proyecto A para convertir esa funcionalidad en una biblioteca, que luego se vincula a ambos. el resto del proyecto A y el proyecto B, y posiblemente también los proyectos C, D y E, todo ello sin imponer los gastos generales de COM, RPC de procedimientos cruzados, etc.

Ahora, no me malinterpreten: no estoy tratando de actuar como portavoz de software de código abierto, ni de decir que el código cerrado es terrible y que el código abierto siempre es dramáticamente superior. Lo que estoy diciendo es que COM se define principalmente a nivel binario, pero para el software de código abierto, las personas tienden a lidiar más con el código fuente.

Edición: probablemente debería agregar que SWIG fue solo un ejemplo entre varias de las herramientas que admiten el desarrollo en varios idiomas a nivel de código fuente. Si bien SWIG se usa ampliamente, COM es diferente de él en una forma bastante crucial: con COM, usted define una interfaz en un solo idioma neutral y luego genera un conjunto de enlaces de idioma (proxies y stubs) que se ajustan a esa interfaz. Esto es bastante diferente de SWIG, donde se hace coincidir directamente de una fuente a un idioma de destino (por ejemplo, enlaces para usar una biblioteca de C de Python).

En el mundo de código abierto también hay herramientas para definir una interfaz en un lenguaje de definición de interfaz neutral, y luego generar enlaces para idiomas específicos a partir de esa definición de interfaz. CORBA es bien conocido, pero generalmente se considera grande y complejo, por lo que el uso real es bastante mínimo. Apache Thrift proporciona algunas de las mismas capacidades generales, pero de una manera más simple y liviana. En particular, donde CORBA intenta proporcionar un conjunto completo de herramientas para la computación distribuida (completa con todo, desde la autenticación hasta el tiempo distribuido), Thrift sigue mucho más de cerca la filosofía de Unix, intentando satisfacer exactamente una necesidad: generar proxies y talones desde una Definición de la interfaz (escrita en un lenguaje neutral). Si quiere hacer esas cosas similares a CORBA con Thrift, sin duda puede hacerlo, pero en un caso más típico de construcción de infraestructura interna en la que la persona que llama y la persona que llama confían entre sí, puede evitar muchos gastos generales y simplemente continuar con el negocio en mano.

Una respuesta rápida a la última pregunta: COM está lejos de ser obsoleto. Casi todo en el mundo de Microsoft está basado en COM, incluido el motor .NET (el CLR) e incluido el nuevo Windows Runtime de Windows 8.x.

Esto es lo que Microsoft dice sobre .NET en sus últimas páginas de C ++. Bienvenido de nuevo a C ++ (Modern C ++) :

C ++ está experimentando un renacimiento porque el poder es el rey otra vez. Los lenguajes como Java y C # son buenos cuando la productividad del programador es importante, pero muestran sus limitaciones cuando la potencia y el rendimiento son primordiales. Para una alta eficiencia y potencia, especialmente en dispositivos que tienen hardware limitado, nada supera a C ++ moderno.

PS: lo que es un poco chocante para un desarrollador que ha invertido más de 10 años en .NET :-)