c++ - template - ¿Para qué sirve el proyecto($ Foo) PS en mi solución $ Foo ATL?
active template library (3)
Crear un proyecto ATL en MSVC parece crear no uno sino dos proyectos; el último nombró igual que el anterior pero con PS anexado a su nombre. ¿Cuál es el propósito de este segundo proyecto y cómo puedo saber si lo necesito?
COM admite realizar llamadas de método de interfaz a través de dos subprocesos diferentes, dos procesos diferentes o dos máquinas diferentes. Esto se llama cálculo de referencias . Dos hebras diferentes es el caso más común, un servidor COM a menudo no es seguro para subprocesos. COM implementa la seguridad de subprocesos para dichas clases de subprocesos de un solo subproceso al calcular la llamada del subproceso "incorrecto" al subproceso que creó el servidor. La acumulación de procesos se produce cuando se escribe un servidor fuera de proceso. Entre diferentes máquinas a través de una red se llama DCOM.
Esto se implementa creando una instancia de la interfaz que se ve exactamente como la original. Pero todos los métodos de la interfaz son en realidad sustitutos que hacen el trabajo de calcular la llamada. Este es el proxy. En el otro extremo del cable hay un sustituto que se ve exactamente como la interfaz pero que hace el trabajo opuesto. Este es el talón. El proxy y el código auxiliar funcionan juntos para crear la ilusión de que está realizando una llamada a un método simple en su programa.
El trabajo principal del proxy es serializar los argumentos de la llamada al método en un búfer de memoria o paquete de red. Esto puede ser bastante trivial, especialmente cuando usas punteros a estructuras de tamaño variable. COM necesita ayuda para hacerlo bien y ese es el trabajo de su proyecto FooPS. Cuando ejecuta midl.exe en su archivo .idl, midl genera automáticamente código a partir de las definiciones de la interfaz para implementar el proxy y el código auxiliar. Esto suele ser bastante bueno, pero es posible que deba implementar el suyo propio si las palabras clave integradas en midl no son suficientes para describir sus datos.
Por último, pero no por ello menos importante, Windows proporciona un contador de referencias estándar que puede calcular interfaces simples. Diseñado para admitir el subconjunto de COM definido por COM Automation. En otras palabras, las interfaces que se derivan de IDispatch y solo usan tipos compatibles de automatización. Solo necesita obtener las entradas de registro correctas para habilitarlo y no necesita el proxy / código auxiliar generado por midl. Y, por supuesto, si solo hace llamadas en proceso en un hilo, tampoco lo necesitará. Esto es bastante común.
Como dijo @ebutusov, el proyecto * PS contiene implementaciones para Proxy y Stub . No son estándar, en su lugar, son generados por MIDL para las interfaces exportadas desde su servidor ATL. Estas interfaces se declaran en el archivo * .IDL. La salida del proyecto es DLL. Puedes leer este artículo para obtener más detalles.
Puede eliminar el proyecto PS de la solución en caso de que no defina ninguna interfaz personalizada en su archivo * .IDL o si solo define interfaces que tienen modificadores duales y de moderación. En ese caso se utilizará un caracterizador de caracteres estándar.
Para poder hacer uso de typelib marshaller estándar, uno tiene que registrar una biblioteca de tipos (que se realiza automáticamente ya que está utilizando ATL)
Es un código proxy / código auxiliar, que contiene los agentes de datos no estándar necesarios para transferir datos entre diferentes departamentos (relacionados con los hilos). Se usa cuando la aplicación, que llama a su objeto COM, usa un modelo de subprocesamiento COM diferente. Hubo una opción en el asistente de ATL / COM para combinar este código en la biblioteca principal. En muchos escenarios comunes, no tiene que preocuparse por eso (es decir, cuando su dll COM se ejecuta en el contexto del cliente), a menos que desee escribir un contador de referencias personalizado.