-
Notifications
You must be signed in to change notification settings - Fork 6
Preprocessor Macros
The PMDA++ library supports a number of preprocessor macros that can be used to alter the library's behaviour.
If the PCP_CPP_DEBUG_COMMAND_LINE_OPTIONS macro is defined, the library will log the state of parsed command line options. As the name implies, this is for debugging only, but can be very helpful when overriding pcp::pmda::parse_command_line.
By default, all PMDA++ classes are contained within the pcp namespace, for example the pcp::pmda class. The PCP_CPP_NAMESPACE macro may optionally be set to the name of an additional namespace to wrap all PMDA++ classes to avoid any potential namespace clash issues.
For example:
#define PCP_CPP_NAMESPACE my_custom_namespace
#include <pcp-cpp/pmda.hpp>
class my_pmda : public my_custom_namespace::pcp::pmda {
}By default, PMDA++ will use Boost libraries for some additional functionality / feature enhancements. However, you may define PCP_CPP_NO_BOOST to exclude these if you do not want any Boost dependencies.
With Boost support enabled (the default), the Boost Program Options library is used to provide significantly more flexible command line parsing - both for internal options, and custom options that may be added by overriding the relevant virtual functions. Without Boost, the built-in command line parsing is reduced to being little more than that which is built in to the official PCP PMDA library (libpcp_pmda).
Of course, you're always free to override pcp::pmda::parse_command_line to implement any parsing conventions you wish regardless of whether or not you're using Boost.
By default, the PMDA++ library will validate metric and instance IDs before calling virtual functions that use them. This allows you, the developer, to get on with the work of exposing metrics, without having to continually reinvent the is-this-ID-valid checks in your code.
However, there is (at least in theory) a very small performance cost associated with this check (it really is very small). So you may, if desired, define the PCP_CPP_NO_ID_VALIDITY_CHECKS macro to have the library not perform such checks. Note, if you do this, the PCP framework still requires you to perform the relevant validity / range checks, but if you choose your metric cluster, metric item, and instance IDs carefully, then you may be able to implement custom ID checking that is slightly more CPU efficient than the generic checks built into PMDA++.
Note: Setting the PCP_CPP_NO_ID_VALIDITY_CHECKS macro also means that the pmda::metric_id::type member will always be set to PM_TYPE_UNKNOWN in calls to pmda::fetch_value. This is because the metric type lookup, which is provided as a convenience only, is performed as part of the ID validation check. Indeed, the same CPU work must be performed for both, so there's no point enabling / disabling one without the other. This means that if you do perform your own explicit validation checks, then you also need to determine for yourself which metrics use which PM data types (as is the case with traditional C PMDAs).
In short, use PMDA++'s built-in validity checks - they save you a lot of manual effort :)
The PCP_CPP_PMDA_INTERFACE_VERSION macro defines the PMDA interface version to use. If not set externally, PMDA++ will default it internally the latest version supported by the currently installed PCP PMDA library (ie PCP's PMDA_INTERFACE_LATEST macro).
You may choose to set this macro to an explicit interface version number, such as 4, to support older versions of PCP than your currently installed PCP headers.