libzypp
10.5.0
|
A simple filter is a function or functor matching the signature: More...
Classes | |
struct | zypp::resfilter::ByName |
Select ResObject by name. More... | |
struct | zypp::resfilter::ByRepository |
Select ResObject by repository or repository alias. More... | |
struct | zypp::resfilter::ByEdition< _Compare > |
Select ResObject by Edition using _Compare functor. More... | |
struct | zypp::resfilter::ByArch< _Compare > |
Select ResObject by Arch using _Compare functor. More... | |
struct | zypp::resfilter::ByInstalled |
Select PoolItem by installed. More... | |
struct | zypp::resfilter::ByUninstalled |
Select PoolItem by uninstalled. More... | |
struct | zypp::resfilter::ByTransact |
Select PoolItem by transact. More... | |
struct | zypp::resfilter::ByLock |
Select PoolItem by lock. More... | |
struct | zypp::resfilter::ByKeep |
Select PoolItem by keep. More... | |
struct | zypp::resfilter::ByRecommended |
PoolItem which is recommended. More... | |
struct | zypp::resfilter::BySuggested |
PoolItem which is suggested. More... | |
Typedefs | |
typedef std::unary_function < ResObject::constPtr, bool > | zypp::resfilter::ResObjectFilterFunctor |
typedef boost::function< bool(ResObject::constPtr)> | zypp::resfilter::ResFilter |
typedef std::unary_function < PoolItem, bool > | zypp::resfilter::PoolItemFilterFunctor |
Functions | |
template<class _Res > | |
filter::ByKind | zypp::resfilter::byKind () |
template<class _Compare > | |
ByEdition< _Compare > | zypp::resfilter::byEdition (const Edition &edition_r, _Compare cmp_r) |
template<class _Compare > | |
ByEdition< _Compare > | zypp::resfilter::byEdition (const Edition &edition_r) |
template<class _Compare > | |
ByArch< _Compare > | zypp::resfilter::byArch (const Arch &arch_r, _Compare cmp_r) |
template<class _Compare > | |
ByArch< _Compare > | zypp::resfilter::byArch (const Arch &arch_r) |
Variables | |
ZYPP_DEPRECATED typedef filter::ByKind | zypp::resfilter::ByKind |
Select ResObject by kind. |
A simple filter is a function or functor matching the signature:
bool simplefilter( ResObject::Ptr );
bool
. Anything which is convertible into a bool
will do;Besides basic filter functors which actually evaluate the ResObject
(e.g. ByKind, ByName) you may use Functors for building compex queries. to build more complex filters.
// some 'action' functor, printing and counting // ResObjects. struct PrintAndCount { PrintAndCount( unsigned & counter_r ) : _counter( counter_r ) {} bool operator()( ResObject::Ptr p ) const { DBG << *p << endl; ++_counter; return true; } unsigned _counter; }; ResStore store; unsigned counter = 0; // print and count all resolvables store.forEach( PrintAndCount(counter) ); // print and count all resolvables named "kernel" counter = 0; store.forEach( ByName("kernel"), PrintAndCount(counter) ); // print and count all Packages named "kernel" counter = 0; store.forEach( chain( ByKind(ResKind::package), ByName("kernel") ), PrintAndCount(counter) ); // print and count all Packages not named "kernel" counter = 0; store.forEach( chain( ByKind(ResKind::package), not_c(ByName("kernel")) ), PrintAndCount(counter) ); // same as above ;) counter = 0; store.forEach( chain( ByKind(ResKind::package), chain( not_c(ByName("kernel")), PrintAndCount(counter) ) ), true_c() );
As you can see in the last example there is no difference in using a filter or an action functor, as both have the same signature. A difference of course is the way forEach interprets the returned value.
Consequently you can netgate and chain actions as well. Thus PrintAndCount(counter)
could be chain(Print(),Count(counter))
, if these functors are provided.
std::ptr_fun, mem_fun, bind1st, bind2nd and compose
. They are sometimes quite helpfull.PrintAndCount
is an example how a functor can return data collected during the query. You ca easily write a collector, that takes a std:list<ResObject::Ptr>&
and fills it with the matches found.
But as a rule of thumb, a functor should be lightweight. If you want to get data out, pass references to variables in (and assert these variables live as long as the query lasts). Or use FunctorRef.
Internally all functors are passed by value. Thus it would not help you to create an instance of some collecting functor, and pass it to the query. The query will then fill a copy of your functor, you won't get the data back. (Well, you probabely could, by using boosr::ref).
Why functors and not plain functions?
You can use plain functions if they don't have to deliver data back to the application. The C-style
approach is having functions that take a void * data
as last argument. This data
pointer is then passed arround and casted up and down.
If you look at a functor, you'll see that it contains both, the function to call (it's operator()
) and the data you'd otherwise pass as void * data
. That's nice and safe.
typedef std::unary_function<ResObject::constPtr, bool> zypp::resfilter::ResObjectFilterFunctor |
Definition at line 151 of file ResFilters.h.
typedef boost::function<bool ( ResObject::constPtr )> zypp::resfilter::ResFilter |
Definition at line 152 of file ResFilters.h.
typedef std::unary_function<PoolItem, bool> zypp::resfilter::PoolItemFilterFunctor |
Definition at line 286 of file ResFilters.h.
filter::ByKind zypp::resfilter::byKind | ( | ) | [related] |
Definition at line 158 of file ResFilters.h.
ByEdition<_Compare> zypp::resfilter::byEdition | ( | const Edition & | edition_r, |
_Compare | cmp_r | ||
) |
Definition at line 227 of file ResFilters.h.
ByEdition<_Compare> zypp::resfilter::byEdition | ( | const Edition & | edition_r | ) |
Definition at line 232 of file ResFilters.h.
ByArch<_Compare> zypp::resfilter::byArch | ( | const Arch & | arch_r, |
_Compare | cmp_r | ||
) |
Definition at line 268 of file ResFilters.h.
ByArch<_Compare> zypp::resfilter::byArch | ( | const Arch & | arch_r | ) |
Definition at line 273 of file ResFilters.h.
ZYPP_DEPRECATED typedef filter::ByKind zypp::resfilter::ByKind |
Select ResObject by kind.
Definition at line 155 of file ResFilters.h.