classe ara::log::Argument

La classe template ara::log::Argument sert, au sein du module log, de type d’encapsulation pour un argument de données utiles et ses attributs. En tant que conteneur de données générique, la structure accepte un argument de type T et devrait permettre le transport avec sûreté de typage vers des puits de journalisation. Question (ouverte) La structure concrète et les membres internes de la classe sont définis de manière spécifique au fournisseur, raison pour laquelle le code d’application portable ne doit pas s’appuyer sur des structures de données spécifiques. L’indication comme final empêche toute dérivation, ce qui devrait favoriser une sémantique de valeur compacte et immuable.

plus ›

Contexte

La classe ara::log::Argument constitue, dans le module de journalisation de l’AUTOSAR Adaptive Platform, un type wrapper générique chargé de recevoir et d’encapsuler un argument de données utiles (Payload Argument) ainsi que ses attributs spécifiques. Conformément à la syntaxe de classe, elle est réalisée sous forme de template avec le paramètre de type T. Cela sert probablement à accueillir des données utiles de types de données primitifs ou complexes quelconques, sans que l’infrastructure de journalisation n’ait besoin de fournir des interfaces distinctes pour chaque type. Question Q-a8237897f16d62c7 (ouverte)

Les partenaires d’interaction sont, d’une part, les composants côté application qui souhaitent consigner des informations d’exécution et, d’autre part, les mécanismes internes de journalisation du module log. Dans les systèmes automobiles distribués et diagnostiquables, la journalisation exige fréquemment non seulement la simple émission d’une valeur brute, mais également l’association de la valeur à des attributs. La classe ara::log::Argument assume ici la tâche de regrouper la donnée et ses caractéristiques descriptives au sein d’une unité logique.

Cycle de vie

La déclaration de la classe sous la forme template <typename T> class Argument final stipule que ara::log::Argument ne peut pas être utilisée comme classe de base pour d’autres spécialisations. Le mot-clé final devrait empêcher délibérément toute dérivation afin de garantir une sémantique de valeur compacte et d’exclure les sources potentielles d’erreurs telles que le découpage d’objets (object slicing) lors de la transmission des arguments. Question Q-cfcfbbdeaad3a21b (ouverte)

La structure de la classe est, selon la spécification AUTOSAR, spécifique au constructeur (implementation-defined). Dès lors, la réalisation interne du stockage, des constructeurs et des champs d’attributs incombe au fournisseur de plateforme respectif. Les développeurs d’applications doivent s’attendre à ce que la représentation interne des attributs et des champs de données varie selon le fournisseur et qu’aucun accès direct aux membres internes ni aucune disposition fixe en mémoire ne doivent donc être présumés. Question Q-0630c61b22bcaab0 (ouverte)

En ce qui concerne les relations de propriété et la durée de vie, les instances de ara::log::Argument sont généralement créées avec une courte durée de vie. Elles apparaissent dans le contexte d’une opération de journalisation imminente, transmettent l’argument de données utiles aux flux ou tampons de journalisation correspondants et sont à nouveau libérées après l’achèvement du processus d’écriture. En matière de concurrence, la structure définie par le constructeur implique que l’accès concurrent à la même instance sans synchronisation externe doit être évité. Il est recommandé d’instancier et de traiter les instances d’argument localement dans le thread d’exécution respectif.

Parcours d'utilisation

Le chemin d’utilisation conceptuel de ara::log::Argument se divise en phases d’encapsulation, de transmission et de traitement :

• Création et encapsulation : une valeur de données utiles de type T est encapsulée avec ses attributs associés dans une instance de ara::log::Argument<T>.
• Transmission au système de journalisation : l’argument encapsulé est transmis aux interfaces du module log, par exemple via des opérateurs de flux (streaming) ou des fonctions de journalisation.
• Traitement et formatage : le framework de journalisation évalue la valeur de données utiles encapsulée ainsi que ses attributs, formate la sortie selon le puits configuré (par exemple console, backend DLT ou mémoire persistante) et sérialise les données.
• Destruction : à la fin de l’instruction de journalisation, le cycle de vie de l’objet argument temporaire se termine automatiquement par la sortie de la portée.

Grâce à ce déroulement standardisé, la classe garantit que les attributs des données utiles sont transportés de manière cohérente avec la valeur des données utiles, sans que le code applicatif n’ait à gérer des structures de tampons propriétaires.