config.hpp File Reference

#include "flow/log/log.hpp"
#include "flow/log/detail/component_cfg.hpp"
#include <boost/unordered_map.hpp>
#include <atomic>
#include <typeinfo>
#include <utility>

Go to the source code of this file.

Classes
class	flow::log::Config
	Class used to configure the filtering and logging behavior of Loggers; its use in your custom Loggers is optional but encouraged; supports dynamically changing filter settings even while concurrent logging occurs. More...
struct	flow::log::Config::Component_config
	The set of config stored for each distinct (as determined by Component::payload_type(), essentially C++ built-in std::type_info) component payload type (in English – component enum class). More...
class	flow::log::Config::Atomic_raw_sev
	Trivial wrapper of atomic<raw_sev_t> which adds a couple of things to make it possible to construct, and therefore use, a vector of such atomics. More...

Namespaces
namespace	flow
	Catch-all namespace for the Flow project: A collection of various production-quality modules written in modern C++17, originally by ygoldfel.
namespace	flow::log
	Flow module providing logging functionality.

Macros
#define	FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_PTR   value_for_exposition
	Macro (preprocessor symbol) to optionally set (when building Flow and translation units that use flow::log::Config) to override a certain flow::log::Config internal behavior that can affect flow::log::Logger::should_log() perf. More...
#define	FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_VAL   value_for_exposition
	Cousin of FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_PTR, similarly affecting a related behavior. More...

Macro Definition Documentation

FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_PTR

#define FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_PTR   value_for_exposition

Macro (preprocessor symbol) to optionally set (when building Flow and translation units that use flow::log::Config) to override a certain flow::log::Config internal behavior that can affect flow::log::Logger::should_log() perf.

Typically there is no need to set this, especially if when calling flow::log::Config::init_component_to_union_idx_mapping() one always provides arg value component_payload_type_info_ptr_is_uniq = false (safe default). (Note: It is recommended to in fact set it to true.) So, if relevant, and if your benchmarks show should_log() is using significant processor cycles, it can make sense to experiment by setting this to other values; namely:

• "::flow::log::Component_payload_type_dict_by_ptr_via_tree_map"
• "::flow::log::Component_payload_type_dict_by_ptr_via_s_hash_map"
• "::flow::log::Component_payload_type_dict_by_ptr_via_b_hash_map"
• "::flow::log::Component_payload_type_dict_by_ptr_via_array"
• "::flow::log::Component_payload_type_dict_by_ptr_via_sorted_array"

Adventurous types can also implement their own such a template, as long as it implements the semantics of "flow::log::Component_payload_type_dict_by_ptr_via_tree_map".

See also

flow::log::Config class doc header Performance section for an overall recipe.

Impl: The chosen default

Regarding the default value: Briefly (this requires understanding of Component_payload_type_dict): All choices are pretty good, as all rely on pointers and not long type names, but reassuringly std::unordered_map (with boost::unordered_map very close) tends to be the best or close, though with only 2 types in the map linear-search array can be marginally better. (GNU STL used here; LLVM STL might be different.)

Definition at line 59 of file config.hpp.

FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_VAL

#define FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_VAL   value_for_exposition

Cousin of FLOW_LOG_CONFIG_COMPONENT_PAYLOAD_TYPE_DICT_BY_PTR, similarly affecting a related behavior.

Again typically there is no need to set this, especially if when calling flow::log::Config::init_component_to_union_idx_mapping() one always provides arg value component_payload_type_info_ptr_is_uniq = true. Otherwise, and if your benchmarks show should_log() is using significant processor cycles, it can make sense to experiment by setting this to other values; namely:

• "::flow::log::Component_payload_type_dict_by_val_via_tree_map"
• "::flow::log::Component_payload_type_dict_by_val_via_s_hash_map"
• "::flow::log::Component_payload_type_dict_by_val_via_b_hash_map"
• "::flow::log::Component_payload_type_dict_by_val_via_array"
• "::flow::log::Component_payload_type_dict_by_val_via_sorted_array"

Adventurous types can also implement their own such a template, as long as it implements the semantics of "flow::log::Component_payload_type_dict_by_val_via_tree_map".

See also

flow::log::Config class doc header Performance section for an overall recipe.

Impl: The chosen default

Regarding the default value: This is the slower lookup type, and may be irrelevant, but within this category we can still do better or worse. As noted in flow::log::Config::Component_payload_type_to_cfg_map doc header by far the worst are the hash-maps; so not that. As of this writing that leaves sorted-map-based; linear-search array; and binary-search array. Empirically (presumably due to the <= ~10 # of types in map) the linear-search array is best, though when closer to 10 types for some hardware binary-search array works best. They are close, though, and across different hardware/software settings we've tried to run the unit-test benchmark it's tough to get completely solid results that would hold for everyone. (GNU STL used here; LLVM STL might be different.)

Definition at line 90 of file config.hpp.