estrutura <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 |
Guia do utilizadorGERADO POR IA
Agrupa, como estrutura de dados gerada, todos os argumentos de saída de um método de serviço para retorno no skeleton.
Agrupa, como estrutura de dados gerada, todos os argumentos de saída de um método de serviço para retorno no skeleton.
A estrutura agrupa todos os argumentos de saída de um método de interface de serviço no lado do servidor para transmissão ao chamador. Durante a execução de um método do skeleton, a implementação do serviço instancia essa estrutura de dados, preenche seus atributos com os resultados calculados e a devolve à camada de comunicação. A middleware serializa subsequentemente os parâmetros contidos e transmite o pacote de resposta ao proxy chamador. Como não há requisitos de especificação explícitos definidos no payload, os tipos de elementos devem corresponder diretamente aos tipos de dados dos parâmetros de saída modelados na interface de serviço. Pergunta Q-55d242e98cd76967 (aberta)
Contexto
A estrutura C++ <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output é um componente gerado da parte de serviço no módulo com da AUTOSAR Adaptive Platform (release R25-11). Dentro da interface de serviço, este tipo agrupa todos os argumentos de saída (parâmetros de saída) de um método de serviço definido no lado do provedor. A estrutura atua como uma camada de mediação entre a implementação concreta de serviço do provedor e a middleware de comunicação ara::com. Como as assinaturas de funções em C++ normalmente suportam apenas um único valor de retorno, este tipo fornece um agregado estruturado para retornar métodos com múltiplos parâmetros de saída de forma segura em relação aos tipos (type-safe) ao ambiente de tempo de execução chamador.
Ciclo de vida
A criação de uma instância de <Method>Output ocorre no contexto de aplicação do provedor de serviço assim que um método de serviço tiver concluído os cálculos solicitados. A implementação do serviço instancia o agregado de dados localmente, inicializa as variáveis-membro nele declaradas com os valores determinados e transfere em seguida a instância para a camada de comunicação. Com a entrega ao framework, encerram-se os direitos de posse imediatos da implementação de método específica da aplicação; o objeto é transferido para a área de responsabilidade da middleware. O tempo de vida da instância é transiente e termina assim que a camada de comunicação tiver serializado os parâmetros contidos nos payloads de protocolo posteriores e liberado o buffer. Quanto à concorrência, cada chamada de método é isolada: cada contexto de chamada opera em sua própria instância, de modo que nenhum mecanismo de sincronização no nível de classe é necessário, desde que os valores transportados não compartilhem recursos comuns desprotegidos.
Caminho de utilização
O fluxo típico no uso de <Method>Output realiza-se em uma sequência fixa de interação entre o ambiente de tempo de execução, a implementação do método skeleton e a estrutura de saída. Após a chegada de uma solicitação de método, a middleware encaminha a chamada para a classe skeleton implementada. A lógica de aplicação realiza o processamento, cria a estrutura <Method>Output e preenche todos os parâmetros de saída. Em seguida, a instância é transmitida ao sistema de tempo de execução, que efetua a serialização e envia a mensagem de resposta pela rede ao proxy requisitante.
Diagrama de sequência: caminho de chamada e de retorno ao utilizar a estrutura Output no skeleton. Fontes: nenhuma referência especificada no payload.
Cenários de erro
Como mero agregado de dados, <Method>Output não dispõe de rotinas próprias de tratamento de erros ou de métodos de estado. Estados errôneos surgem primariamente nas interfaces por meio de inicialização incompleta ou violação de pré-condições. Se a implementação do lado da aplicação deixar de preencher corretamente variáveis-membro individuais antes do retorno, valores não inicializados ou estados nulos poderão ser serializados. Se o cálculo funcional do método de serviço falhar previamente, nenhuma instância válida de <Method>Output será transmitida no fluxo de controle regular; em vez disso, a implementação relatará o erro ocorrido por meio dos canais de erro designados da interface de serviço. Caso ocorram erros de alocação de memória em estruturas dinâmicas de dados dentro dos argumentos de saída, eles deverão ser interceptados dentro do método chamado antes de ocorrer a transferência para a middleware.
Este guia baseia-se nas informações estruturais do payload da Adaptive Platform (release R25-11, módulo com). Como não há referências específicas de requisitos SWS no payload, os fluxos funcionais foram descritos de forma neutra com base na sintaxe de interface declarada.
gemini-3.8-flash-low· 2026-10-13 · Original em alemão