From: Florian Stegner <FlSt@gmx.de>
Rob Stewart wrote:
From: FlSt@gmx.de
My suggestion for each_of was to handle the situation in which each could match independently, whereas with all_of, each must match the same other value. IOW, given ranges L and R, each_of(L) == any_of(R) means that each value in L may match any value in R, whereas all_of(L) == any_of(R) means each value in L must match any single value in R. Thus, if L[n] == R[m] for any n in L and m in R, each_of(L) == any_of(R) is true. However, for all_of(L) == any_of(R), all values of L must equal R[m] for any m in R.
Now I understand it. If you compare our implementations, this is exactly what not_all_of in my implementation does.
Does that mean that your not_all_of presently means all, but each taken individually, like my each_of, and that you will change it to mean any number less than all? Or have I misunderstood what you were saying?
"all_except_one" is quite common situation which may be considered too.
This is also the same like not_all_of
No. "all_except_one," or maybe "all_but_one," means exactly N - 1 matches, where N is the length of the range.
Yes your are right. It is the same like one_of where the result of the predicate is negated. I wouldn't add too much xxx_of operators, because the most expressions of them can be formulated with others. one_of( a ) > x means the same as all_except_one( a ) <= x
We can get to the point of adding too many *_of operations, but we do need to cover the common ones. Certainly all_but_one is the same as one_of after negating the predicate, but it may prove to be sufficiently common that users will want it. It's a balancing act, but if there's enough interest, it is better that we define the operation once in the library. Perhaps the right initial approach is to provide those needed to build everything one might need, plus a few very common simplifying ones, and perhaps document the others that one could define. We'll also want to document how to create new ones. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;