estructura <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output
struct <Method>Output {...};
Structure wrapping the out arguments for a method
| Header-Datei | #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton.h" |
|---|---|
| Forwarding-Header | #include "<SiNamespaceDerivedDirectoryPath>/<SiShortname>_skeleton/<SiShortname>_skeleton_fwd.h" |
| Scope | class <SI-Namespace>::skeleton::<SI>Skeleton |
Guía del usuarioGENERADO POR IA
Agrupa como estructura de datos generada todos los argumentos de salida de un método de servicio para su retorno en el skeleton.
Agrupa como estructura de datos generada todos los argumentos de salida de un método de servicio para su retorno en el skeleton.
La estructura agrupa todos los argumentos de salida de un método de Service Interface en el lado del servidor para su transmisión al llamador. Durante la ejecución de un método del skeleton, la implementación del servicio instancia esta estructura de datos, rellena sus atributos con los resultados calculados y la devuelve a la capa de comunicación. A continuación, el middleware serializa los parámetros contenidos y transmite el paquete de respuesta al proxy llamador. Dado que en el payload no se recogen requisitos explícitos de especificación, es de esperar que los tipos de elementos se correspondan directamente con los tipos de datos de los parámetros de salida modelados en el Service Interface. Pregunta Q-55d242e98cd76967 (abierta)
Contexto
La estructura de C++ <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output es un componente generado de la parte de servicio en el módulo com de AUTOSAR Adaptive Platform (versión R25-11). Dentro de la interfaz de servicio, este tipo agrupa todos los argumentos de salida (parámetros Out) de un método de servicio definido en el lado del proveedor. La estructura actúa como capa de mediación entre la implementación concreta del servicio por parte del proveedor y el middleware de comunicación ara::com. Puesto que las firmas de funciones en C++ habitualmente solo admiten un único valor de retorno, este tipo proporciona un agregado estructurado para devolver a la capa de ejecución llamadora métodos con múltiples parámetros de salida de forma segura respecto a tipos.
Ciclo de vida
La creación de una instancia de <Method>Output tiene lugar en el contexto de aplicación del proveedor de servicio una vez que un método de servicio ha completado los cálculos requeridos. La implementación del servicio instancia localmente el agregado de datos, inicializa las variables miembro declaradas en él con los valores obtenidos y, seguidamente, transfiere la instancia a la capa de comunicación. Con la transferencia al framework finalizan los derechos de posesión inmediatos de la implementación del método específica de la aplicación; el objeto pasa al ámbito de responsabilidad del middleware. La vida útil de la instancia es transitoria y finaliza tan pronto como la capa de comunicación serializa los parámetros contenidos en los payloads de protocolo posteriores y libera el búfer. En lo relativo a la concurrencia, cada llamada a un método está aislada: cada contexto de llamada opera sobre su propia instancia, por lo que no se requieren mecanismos de sincronización a nivel de clase mientras los valores transportados no compartan recursos comunes no protegidos.
Ruta de uso
La secuencia típica al utilizar <Method>Output se desarrolla en una interacción fija entre el entorno de ejecución, la implementación del método del skeleton y la estructura de salida. Tras la llegada de una consulta de método, el middleware reenvía la llamada a la clase skeleton implementada. La lógica de aplicación lleva a cabo el procesamiento, crea la estructura <Method>Output y rellena todos los parámetros de salida. A continuación, la instancia se transmite al sistema de ejecución, el cual realiza la serialización y envía el mensaje de respuesta a través de la red al proxy solicitante.
Diagrama de secuencia: ruta de llamada y retorno al utilizar la estructura Output en el skeleton. Fuentes: no se especifican referencias en el payload.
Escenarios de error
Como mero agregado de datos, <Method>Output no dispone de rutinas propias de tratamiento de errores ni de métodos de estado. Los estados erróneos surgen principalmente en las interfaces debido a una inicialización incompleta o a la vulneración de precondiciones. Si la implementación en el lado de la aplicación omite asignar valores correctamente a variables miembro individuales antes del retorno, se pueden serializar valores no inicializados o estados nulos. Si el cálculo funcional del método de servicio falla de antemano, en el flujo de control regular no se transmite ninguna instancia válida de <Method>Output; en su lugar, la implementación notifica el error producido a través de los canales de error previstos para ello en la interfaz de servicio. Si se producen errores de asignación de memoria con estructuras de datos dinámicas dentro de los argumentos de salida, estos deben capturarse dentro del método invocado antes de que se realice la transferencia al middleware.
Esta guía se basa en los datos estructurales del payload de Adaptive Platform (versión R25-11, módulo com). Dado que en el payload no constan referencias específicas a requisitos SWS, las secuencias funcionales se han descrito de forma neutral a partir de la sintaxis declarada de la interfaz.
gemini-3.8-flash-low· 2026-10-13 · Original en alemán