class ara::log::Argument

The template class ara::log::Argument serves within module log as an encapsulation type for a payload argument and its attributes. As a generic data carrier, the structure accepts an argument of type T and is likely to enable type-safe transport to logging sinks. Question (open) The concrete design and the internal members of the class are defined vendor-specifically, which is why portable application code should not rely on specific data structures. Being marked as final prevents derivation, which is likely to support compact and immutable value semantics.

more ›

Context

Class ara::log::Argument forms a generic wrapper type in the logging module of the AUTOSAR Adaptive Platform that is responsible for accommodating and encapsulating a payload argument together with its specific attributes. According to the class syntax, it is realized as a template with the type parameter T. This presumably serves to accommodate payload data of arbitrary primitive or complex data types without the logging infrastructure having to provide separate interfaces for each type. Question Q-a8237897f16d62c7 (open)

Application-side components that want to log runtime information act as interaction partners on the one hand, and the internal logging mechanisms of module log on the other. In distributed and diagnosable automotive systems, logging often requires not only the mere output of a bare value, but also linking the value with attributes. Class ara::log::Argument assumes the task of combining the datum and its descriptive characteristics into a logical unit.

Lifecycle

The declaration of the class as template <typename T> class Argument final specifies that ara::log::Argument cannot be used as a base class for further specializations. Derivation is likely to be deliberately prevented by the final keyword in order to ensure compact value semantics and rule out potential error sources such as object slicing during argument forwarding. Question Q-cfcfbbdeaad3a21b (open)

According to the AUTOSAR specification, the internal structure of the class is vendor-specific (implementation-defined). Therefore, the internal realization of storage, constructors, and attribute fields is left to the respective platform provider. Application developers should be prepared for the internal representation of attributes and data fields to vary vendor-specifically, meaning that no direct access to internal members or a fixed memory layout may be assumed. Question Q-0630c61b22bcaab0 (open)

With respect to ownership and lifetime, instances of ara::log::Argument are generally created short-lived. They originate in the context of a pending logging operation, transfer the payload argument to the corresponding logging streams or buffers, and are deallocated again after completion of the write operation. Regarding concurrency, the vendor-defined structure implies that concurrent access to the same instance without external synchronization should be avoided. It is recommended to instantiate and process argument instances locally within the respective execution thread.

Usage Path

The conceptual usage path of ara::log::Argument is structured into the phases of encapsulation, forwarding, and processing:

• Creation and encapsulation: A payload value of type T is encapsulated in an instance of ara::log::Argument<T> together with the associated attributes.
• Transfer to the logging system: The encapsulated argument is passed to the interfaces of module log, for example via streaming operators or logging functions.
• Processing and formatting: The logging framework evaluates the encapsulated payload value as well as its attributes, formats the output according to the configured sink (e.g. console, DLT backend, or persistent storage), and serializes the data.
• Destruction: With the termination of the log statement, the lifecycle of the temporary argument object ends automatically by leaving the scope.

Through this standardized flow, the class ensures that payload attributes are transported consistently with the payload value without application code having to manage proprietary buffer constructs.