...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
#include <boost/log/attributes/attribute.hpp
> #include <boost/log/attributes/attribute_value.hpp
> #include <boost/log/attributes/attribute_value_impl.hpp
>
Developing your own attributes is quite simple. Generally, you need to do the following:
impl
interface; this is the attribute value implementation class. This object
will have to implement the dispatch
method that will extract the stored data (or, in other words, the stored
value) to a type dispatcher. In most cases the class attribute_value_impl
provided by the library can be used for this.
attribute_value
class as the interface class that holds a reference to the attribute
value implementation.
constant
attribute
provided by the library), but often there is some logic that needs to
be invoked to acquire the attribute value. This logic has to be concentrated
in a class derived from the impl
interface, more precisely - in the get_value
method. This class is the attribute implementation class. You can think
of it as an attribute value factory.
attribute
.
By convention, the interface class should create the corresponding implementation
on construction and pass the pointer to it to the attribute
class constructor. The interface class may have interface methods but
it typically should not contain any data members as the data will be
lost when the attribute is added to the library. All relevant data should
be placed in the implementation class instead.
While designing an attribute, one has to strive to make it as independent from the values it produces, as possible. The attribute can be called from different threads concurrently to produce a value. Once produced, the attribute value can be used several times by the library (maybe even concurrently), it can outlive the attribute object that created it, and several attribute values produced by the same attribute can exist simultaneously.
From the library perspective, each attribute value is considered independent from other attribute values or the attribute itself. That said, it is still possible to implement attributes that are also attribute values, which allows to optimize performance in some cases. This is possible if the following requirements are fulfilled:
constant
attribute is an example.
As a special case for the second point, it is possible to store attribute
values (or their parts) in a thread-specific storage. However, in that case
the user has to implement the detach_from_thread
method of the attribute value implementation properly. The result of this
method - another attribute value - must be independent from the thread it
is being called in, but its stored value should be equivalent to the original
attribute value. This method will be called by the library when the attribute
value passes to a thread that is different from the thread where it was created.
As of this moment, this will only happen in the case of asynchronous
logging sinks.
But in the vast majority of cases attribute values must be self-contained
objects with no dependencies on other entities. In fact, this case is so
common that the library provides a ready to use attribute value implementation
class template attribute_value_impl
and make_attribute_value
generator function. The class template has to be instantiated on the stored
value type, and the stored value has to be provided to the class constructor.
For example, let's implement an attribute that returns system uptime in seconds.
This is the attribute implementation class.
// The function returns the system uptime, in seconds unsigned int get_uptime(); // Attribute implementation class class system_uptime_impl : public logging::attribute::impl { public: // The method generates a new attribute value logging::attribute_value get_value() { return attrs::make_attribute_value(get_uptime()); } };
Since there is no need for special attribute value classes we can use the
make_attribute_value
function to create the value envelop.
Tip | |
---|---|
For cases like this, when the attribute value can be obtained in a single
function call, it is typically more convenient to use the |
The interface class of the attribute can be defined as follows:
// Attribute interface class class system_uptime : public logging::attribute { public: system_uptime() : logging::attribute(new system_uptime_impl()) { } // Attribute casting support explicit system_uptime(attrs::cast_source const& source) : logging::attribute(source.as< system_uptime_impl >()) { } };
As it was mentioned before, the default constructor creates the implementation instance so that the default constructed attribute can be used by the library.
The second constructor adds support for attribute
casting. The constructor argument contains a reference to an attribute
implementation object, and by calling as
on it the constructor attempts to upcast it to the implementation object
of our custom attribute. The as
method will return NULL
if
the upcast fails, which will result in an empty attribute constructed in
case of failure.
Having defined these two classes, the attribute can be used with the library as usual:
void init_logging() { boost::shared_ptr< logging::core > core = logging::core::get(); // ... // Add the uptime attribute to the core core->add_global_attribute("SystemUptime", system_uptime()); }