2012-07-27 13 views
5

Soy principalmente un chico de C++. Como C++ carece de un ABI oficial, siempre uso un enfoque tipo COM para diseños de componentes que admiten más de un compilador.Objective-C estable ABI

Recientemente me encontré con la pregunta si Objective-C sería un reemplazo para el enfoque tipo COM. Obviamente para que Objective-C sea un reemplazo uno necesitaría un ABI estable, por lo tanto, me gustaría saber si existe un ABI estable para Objective-C (en todos los sistemas operativos principales [OSX, GNU/Linux, Windows]) y qué fácil sería usar Objective-C (++) como "pegamento" entre componentes creados por diferentes compiladores.

EDIT: Como Nikolai Ruhe señaló una breve descripción de COM puede ser útil. COM es esencialmente un "estándar binario" que permite mezclar binarios de diferentes compiladores (y en una variedad de idiomas). El vehículo de COM son las interfaces, que definen los métodos (que se asignan a las funciones virtuales de C++). Los componentes implementan al menos una interfaz y se distribuyen como DLL. Se pueden ubicar en cualquier lugar del sistema (la posición se especifica en el Registro) y cualquier cliente COM puede cargarlos a través de la ID de la interfaz que implementan.

+2

Está obviamente dirigiéndose a personas de Objective-C. Seguramente sería útil si describieras un poco "el enfoque tipo COM". No tengo idea de qué es eso. –

+1

@NikolaiRuhe gracias, acabo de hacer eso, espero que explique cómo funciona COM (en un nivel básico) – MFH

+0

Actualmente tengo mi "propia versión de COM" - bien sin soporte para lenguajes que no son C++ ^^ Solo pensé que tal vez algo como Objective-C++ sería una forma más elegante (ya que cualquier cosa como COM parece ser poco elegante en cierta medida [aunque oculto eso a través de los envoltorios en mi implementación actual]). No es que mi diseño actual no sea utilizable: en realidad estoy generando una gran cantidad de archivos [VTABLES, Wrappers, ...] de un lenguaje simple, pero eso aún agrega la sobrecarga de tener 2 programas en lugar de solo el compilador. .. – MFH

Respuesta

3

Solo puedo hablar sobre la implementación de Apple, ya que no tengo experiencia con el GNU u otros puertos.

Objective-C se basa en la ABI de C en su mayor parte (como las llamadas a funciones y el diseño de la memoria de las estructuras).

propia ABI sufrió un par de cambios en la implementación de Apple, como non-fragile instance variables introducidos con el "Modern Runtime", la introducción de propiedades, gestión de excepciones más rápido, recogida de basuras, __weak apoyo a ARC.

Algunos de los cambios fueron retrocompatibles, otros no. Pero dado que todo el sistema y los marcos son proporcionados por Apple y los cambios generalmente se introdujeron con otros cambios no compatibles (cambiar a Intel y LP64), esto no tuvo consecuencias para los usuarios.

Editar: Una cosa que debes tener en cuenta es que Objective-C no solo depende de un ABI fijo sino también de un tiempo de ejecución compatible. Ese es un dolor de cabeza más para preocuparse por su propósito.

+0

¿Cómo se definen los métodos (más como los mensajes [¿cierto?]) en el nivel binario? No estoy seguro de si la dependencia del tiempo de ejecución sería un gran problema, en comparación con los tiempos de ejecución C (++), ¿cuántos hay para Objective-C (++) para el mismo sistema? – MFH