|
Boost : |
From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-01 08:57:46
From: FlSt_at_[hidden]
>
> I uploaded a new version of the junction comparison of ranges to boost
> sandbox file vault ( flos_junction_v6.zip ). When find it useful or you
You just keep churning them out! Please describe the differences
as you add a new version.
> have critism on the implementation tell it to me. There is still the
> naming problem, i don't want call them junctions. Has anyone an idea?
I've been working on my own implementation which takes a
different tack from yours (as of v3 or 4, I think, anyway). That
has raised some questions, but first, I have an idea for the
naming:
namespace: boost::multivalues
base class: multivalue
all_of: all_values
any_of: any_value
none_of: no_values
one_of: one_value
Are all (in)equality comparisons symmetric? I was pondering what
the following expression means:
any_of(s1) == one_of(s2)
You could make that case that as long as any one of the values in
s1 matches exactly one of the values in s2, the result is true.
Given that interpretation, should the following expression mean
the same thing?
one_of(s2) == any_of(s1)
When written that way, it seems easy to think that there should
only be one value in s1 that matches a value in s2. IOW, if more
than one value in s1 matches exactly one value in s2, the
expression would be false.
Thus, the first expression could also be true iff there is just
one value in s1 that matches exactly one value in s2.
If you think the latter interpretation, then how does that differ
from the following expression?
one_of(s1) == one_of(s2)
That expression clearly says exactly one value in s1 must match
exactly one value in s2. Consequently, I think it argues for the
first two expressions to be true if one or more value in s1
matches exactly one value in s2. Do you agree?
> There are four functions for creating junction-objects from a range:
> any_of, all_of, one_of and none_of and you can compre the objects with
> one of the comparion operators (==,!=,<,<=,>,>=). You also can use
> something different when you write:
>
> any_of( a ).do_comparison( <Function object>, all_of( b ) ); The
> function object exspected is bool(element_type,element_type) wheather
> element_type is the type of a range element.
As soon as you open up that interface, you permit opportunity for
confusion. This is especially true of comparisons with none_of.
It is also a point of customization that must be documented. Do
you think there's enough reason to justify that?
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk