Rob Stewart wrote:
So, I think we're agreed that we're discussing four things that can be compared to each other as well as to single values. The supported comparisons are ==, !=, <, >, <=, and >=. If we're agreed, then we can discuss design.
I aggree. The other aspects of junctions are kept in mind for later discussions.
For the extraction of elements matching some criteria, you would likely use function templates. For the functionality we've whittled down junctions (or whatever name still fits) to include, you need types plus namespace scope operators:
[ ... code ...]
I modified my implementation so that it implements the most of your ideas, like using ranges and call traits. (uploaded to the Boost sandbox files vault as flos_junctions_v2.zip). But there are some differences, how the operators supported. Please take a look at it. I think there are much better ways to do the specialization for the junction types and get rid of the XXjunction-classes and provide only XXX_of as template classes. But this version has the advantage, that it does all the work in one place and the operator implementation is consistent without the need of friend relations. Your approach has also it's adavantages, for example it's easier to implement optimized versions of the junction types. The new implementation is more effecient as before, but i don't like the use of boost::dynamic_bitset, because the result can determined without storing all results. (Only for one_of a flag or something similar is needed). My attempt makes it difficult to make it more efficient without ugly hacking.
A better approach is probably for the operators to be implemented in terms of a number of implementation function templates that work only on junction<T>'s. Then, there's no conversion needed; the operators just need to call the right implementation function. That leaves the four derived types as just selectors for the right operator.
Ideally, junction<T> will hide its range and the implementation function templates will be made friends.
That is what I did without using a friend relation.
What do you think of these ideas for the design?
I think there must be a trade-of between your design ideas and my implementation proposal. (My implementation should only be a prototype) In many points we agreed, but some details are very different. I don't like friend relations (I don't see operators as a part of the class, they are just syntactic sugar) and I think to let the operators do the work for every junction type would produce more duplicated code and more operator overloads as neccessary.
There's still the issue of naming. Should these be called junctions since they don't do all that Perl's junctions do? Besides, I think "junction" somehow fits better the notion of producing a result container that includes those elements of the range that satisfy the criteria.[...]
Ok.. I see, that the naming is a problem now. "Junction" and "supervalues" are not evident. We have now something like a comparison over ranges with a logical linkage between the elements. Would be "range_comparison" or "junction_comparison" better? Sincerly, Florian