#[derive(ManagerEventSubscriber)]
{
// Attributes available to this derive:
#[subscribe]
}
Expand description
Derive the ManagerEventSubscriber trait from oxidd_core::util
ยงExample
#[derive(ManagerEventSubscriber)]
#[subscribe(manager = M)]
struct ManagerData<M> {
apply_cache: ApplyCache<M>,
zbdd_cache: ZBDDCache<M>,
#[subscribe(skip)]
field_to_skip: bool,
}Specifying the manager type via #[subscribe(manager = M)] is mandatory (it
does not need to be a generic parameter, though). The generated
implementation will look like this:
impl<M> ManagerEventSubscriber<M> for ManagerData<M>
where
M: Manager,
ApplyCache<M>: ManagerEventSubscriber<M>,
ZBDDCache<M>: ManagerEventSubscriber<M>,
{
fn pre_gc(&self, manager: &M) {
self.apply_cache.pre_gc(manager);
self.zbdd_cache.pre_gc(manager);
}
unsafe fn post_gc(&self, manager: &M) {
// SAFETY: since the caller ensures to call this method (only!) once
// after a GC, we call `post_gc` (only) once for each substructure.
unsafe {
self.apply_cache.post_gc(manager);
self.zbdd_cache.post_gc(manager);
}
}
// similar implementations for `pre_reorder` and `post_reorder` ...
fn pre_reorder_mut(manager: &mut M) {
ApplyCache::<M>::pre_reorder_mut(manager);
ZBDDCache::<M>::pre_reorder_mut(manager);
}
// similar implementation for `post_reorder_mut` ...
}Note that if you have two fields of the same type (and you do not use
#[subscribe(skip)] on either of these fields), the pre_reorder_mut and
post_reorder_mut implementation will call the method for that type twice
(with the same manager argument).
In some cases the trait bounds M: Manager,
ApplyCache<M>: ManagerEventSubscriber<M>, etc. can lead to undesired
self-references and cause the compiler error
E0275. To disable
the generation of those trait bounds, specify no_trait_bounds via a
struct-level subscribe attribute. (This will not affect trait bounds from
the struct declaration itself.)