Processor concepts and traits

Description

Concepts and traits to check processor capabilities.

Note

Concepts (here and elsewhere in libtcspc) check only the surface signatures of the required members. A satisfied concept does not guarantee that the type and its required members can actually be instantiated: a class-level or member-level static_assert (or other instantiation failure) may still fire when the type is used.

Concepts
concept	tcspc::const_handler_for
	Concept that is satisfied when a processor handles an event type by const lvalue reference.
concept	tcspc::flushable
	Concept that is satisfied when a processor handles flushing.
concept	tcspc::handler_for
	Concept that is satisfied when a processor handles the given event types.
concept	tcspc::processor
	Concept that is satisfied when a processor handles the given event types and flush.
concept	tcspc::rvalue_handler_for
	Concept that is satisfied when a processor handles an event type by rvalue reference.

Variables
template<typename Proc, typename EventList>
constexpr bool	tcspc::handles_event_list_v
	Trait variable to check whether a processor handles a list of event types.
template<typename Proc, typename EventList>
constexpr bool	tcspc::is_processor_of_list_v
	Trait variable to check whether a processor handles a list of event types and flush.

Variable Documentation

handles_event_list_v

template<typename Proc, typename EventList>

bool tcspc::handles_event_list_v

inlineconstexpr

Initial value:

                                       =
internal::handles_event_list_impl<Proc, EventList>::value

Trait variable to check whether a processor handles a list of event types.

Determines whether the processor Proc handles all of the event types in the tcspc::type_list specialization EventList. Equivalent to tcspc::handler_for<Proc, Events...> where Events... is the parameter pack of EventList.

If the event handler(s) exist but any of them has a return type other than void, compilation fails.

Why this is a _v trait, not a concept

Unpacking the type list requires a class-template partial specialization, because C++20 does not permit partial specialization of concepts (only of class and variable templates). A type-list-keyed predicate written as a concept therefore has to route through a helper class template and is structurally <helper-impl>::value — a single atomic constraint. It would not subsume with the pack-keyed tcspc::handler_for concept, so the two could not participate together in concept-subsumption-arbitrated overload resolution. Presenting this predicate as a _v query rather than a peer-named concept avoids implying a subsumption relationship that the language cannot deliver.

Note

A true result indicates that Proc handles the events in EventList provided that Proc and the relevant Proc::handle() overloads can be instantiated (if Proc is a template class). It is possible that instantiation will fail (due to static_assert failures or other issues) even if the result of this trait is true.

is_processor_of_list_v

template<typename Proc, typename EventList>

bool tcspc::is_processor_of_list_v

inlineconstexpr

Initial value:

                                         =
internal::is_processor_of_list_impl<Proc, EventList>::value

Trait variable to check whether a processor handles a list of event types and flush.

Determines whether the processor Proc is move-constructible and handles all of the event types in the tcspc::type_list specialization EventList as well as flush(). Equivalent to tcspc::processor<Proc, Events...> where Events... is the parameter pack of EventList.

If the event handler(s) and/or flush() exist but any of them has a return type other than void, compilation fails.

Why this is a _v trait, not a concept

Unpacking the type list requires a class-template partial specialization, because C++20 does not permit partial specialization of concepts (only of class and variable templates). A type-list-keyed predicate written as a concept therefore has to route through a helper class template and is structurally <helper-impl>::value — a single atomic constraint. It would not subsume with the pack-keyed tcspc::processor concept, so the two could not participate together in concept-subsumption-arbitrated overload resolution. Presenting this predicate as a _v query rather than a peer-named concept avoids implying a subsumption relationship that the language cannot deliver.

Note

A true result indicates that Proc handles flush and the events in EventList provided that Proc, Proc::flush(), and the relevant Proc::handle() overloads can be instantiated (if Proc is a template class). It is possible that instantiation will fail (due to static_assert failures or other issues) even if the result of this trait is true.