From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com>
<FlSt@gmx.de> wrote:
________________________________________________________ 3. There should be overloads of "xyz_of" who take pair of iterators, in the old-fashioned STL way.
Hmmm. That's a good idea. Ranges are nice, but they don't support two iterators unless they are paired somehow.
________________________________________________________ 4. Perhaps the could be rewritten not to use macros as code generators.
It is not possible to debug it as it is now, for example.
That's a good point. I've encountered the issue myself in my implementation.
________________________________________________________ 5. The classes like conjuction etc may be likely moved into sub-namespace like boost::junction_details.
The idea is that you may wish to create and hold onto instances, though I'll grant that most uses are likely to be via the *_of function templates.
________________________________________________________ 6. Would it be possible to have other qualifiers, e.g.: "more_than_half_of"
if (more_than_half_of(a) >= any_of(b)) ...
or more complex versions like:
more_than(10).items_of(a) >= ... more_than(30.1).percents_of(a) == ...
less_than(2).items_of(a) >= ... less_than(95).percents_of(a) == ...
between(1, 5).items_of(a) >= ... between(10.5, 20.0).percents_of(a) == ....
Those are possible but are they sufficiently useful? Do you think they would be used enough to justify creating/documenting them?
exactly(10).items_of(a) >= ....
I already proposed n_of for that: n_of<10>(a) That doesn't read as well as your version, of course.
Comparison between two "mores" would be disabled.
Why?
________________________________________________________ 7. Will it be possible to use other predicates than
, <=, etc in following form:
if ( is_true_that(all_of(a), a_binary_functor, one_of(b)) ) ...
where the functor could be lambda:
if (is_true_that(all_of(a), _1 >= _2, one_of(b)) ....
It feels more natural than the asymetric "do_comparison".
I agree with the asymmetry of do_comparison(), but is it necessary to provide the additional predicate support? Reasoning over the result of using none_of() with a user-defined predicate gets quite difficult when compared against an all_of() or other junction/multivalue objects. Doing so against a single value is much easier. I think "evaluate" is better than "is_true_that:" if (evaluate(all_of(a), _1 >= _2, one_of(b))) ... Should the normal operators rely on lambda support? My implementation uses structs with templated operators to permit heterogenous comparisons, so there's no need for lambda's heavy lifting.
________________________________________________________ 8. If the "is_true_that" will be implemented than a filter "where" could be considered, like:
if ( is_true_that(all_of(a), _1 >= _2, one_of(b) ).where(_1->does_fulfill_condition()) ) ...
and the "where" fould have unary predicate as parameter, this predicate would filter out undesirable items from both ranges.
That doesn't sound like what you've described. I'd expect this to do what you've described: if (evaluate(all_of(a).where(filter1) , _1 >= _2 , one_of(b).where(filter2))) ... However, this would be even better as it wouldn't confuse behavior: if (evaluate(all_of(from(a).select(filter1)) , _1 >= _2 , one_of(from(b).select(filter2)))) ... Nevertheless, the question arises whether all of this is warranted. Indeed, if we support iterator pairs in addition to ranges, there are other libraries that one can employ to do the filtering, so this one doesn't need to. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;