Filters operate on Sink level and determine if a Record will be handled by that Sink object or skipped. Users are able apply provided filter like the ProjectionFilter types or use custom types. Those custom types can be from any type which is invokable by the used Record type and returning a bool (or at least a bool-comparable-type) as result.
There are already some convenience factory function present (e.g. makeMessageProjectionFor), which may help setting up filters quickly.
◆ makeChannelFilterFor()
template<Record TRecord, std::predicate< const RecordChannel_t< TRecord > & > TUnaryPredicate>
| constexpr auto sl::log::makeChannelFilterFor |
( |
TUnaryPredicate && |
predicate | ) |
|
|
constexpr |
Factory function for creating ProjectionFilter of Record::channel member.
- Template Parameters
-
| TRecord | Concrete Record type on which to apply the projection |
| TUnaryPredicate | Invokable type, which has to accept objects the actual Record::Channel_t type |
- Parameters
-
| predicate | Predicate object |
- Returns
- ProjectionFilter object
This is the preferable way creating a filter for the Record::channel member, because the predicate becomes strong checked via concept and therefore will provide much clearer feedback in cases of error, while creating ProjectionFilter objects manually will potentially result in harder to read error message.
◆ makeMessageFilterFor()
template<Record TRecord, std::predicate< const RecordMessage_t< TRecord > & > TUnaryPredicate>
| constexpr auto sl::log::makeMessageFilterFor |
( |
TUnaryPredicate && |
predicate | ) |
|
|
constexpr |
Factory function for creating ProjectionFilter of Record::message member.
- Template Parameters
-
| TRecord | Concrete Record type on which to apply the projection |
| TUnaryPredicate | Invokable type, which has to accept objects the actual Record::Message_t type |
- Parameters
-
| predicate | Predicate object |
- Returns
- ProjectionFilter object
This is the preferable way creating a filter for the Record::message member, because the predicate becomes strong checked via concept and therefore will provide much clearer feedback in cases of error, while creating ProjectionFilter objects manually will potentially result in harder to read error message.
◆ makeSeverityFilterFor()
template<Record TRecord, std::predicate< const RecordSeverity_t< TRecord > & > TUnaryPredicate>
| constexpr auto sl::log::makeSeverityFilterFor |
( |
TUnaryPredicate && |
predicate | ) |
|
|
constexpr |
Factory function for creating ProjectionFilter of Record::severity member.
- Template Parameters
-
| TRecord | Concrete Record type on which to apply the projection |
| TUnaryPredicate | Invokable type, which has to accept objects the actual Record::SeverityLevel_t type |
- Parameters
-
| predicate | Predicate object |
- Returns
- ProjectionFilter object
This is the preferable way creating a filter for the Record::severity member, because the predicate becomes strong checked via concept and therefore will provide much clearer feedback in cases of error, while creating ProjectionFilter objects manually will potentially result in harder to read error message.
◆ makeTimePointFilterFor()
template<Record TRecord, std::predicate< const RecordTimePoint_t< TRecord > & > TUnaryPredicate>
| constexpr auto sl::log::makeTimePointFilterFor |
( |
TUnaryPredicate && |
predicate | ) |
|
|
constexpr |
Factory function for creating ProjectionFilter of Record::timePoint member.
- Template Parameters
-
| TRecord | Concrete Record type on which to apply the projection |
| TUnaryPredicate | Invokable type, which has to accept objects the actual Record::TimePoint_t type |
- Parameters
-
| predicate | Predicate object |
- Returns
- ProjectionFilter object
This is the preferable way creating a filter for the Record::timePoint member, because the predicate becomes strong checked via concept and therefore will provide much clearer feedback in cases of error, while creating ProjectionFilter objects manually will potentially result in harder to read error message.
1.9.1