From: FlSt@gmx.de
Rob Stewart wrote:
From: Florian Stegner <FlSt@gmx.de>
Rob Stewart wrote:
Nah, like this:
set<int> a; all_values<set<int> > all_of_a(all_of(a));
I've nearly got that ready plus I'm using your dispatch technique. I'll upload it when I get it compiling.
I updated multivalues.zip (http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&filename=multivalues.zip&directory=rob_stewart&). This version uses your dispatch technique, supports iterators, and provides user-level types such as all_value. I also changed n_m_of to use runtime values in preparation for implementing the between and exactly stuff Pavel suggested. I think this will also reduce template instantiations and, thus, improve compile times, at least a little.
2. You don't have iterator range support yet.
This will be the next point I will work on.
Take a look at mine. My next version will follow your dispatch technique, so you might just want to wait for that one.
I will wait. :-)
Your wait is over! ;-) Let me know what you think.
4. I see that you've made good use of implementing one type in terms of another. I did that early on in my operator intensive version and ignored it after refactoring my library. I need to revisit that.
That was the thing which makes the 10% runtime differences between our implementations without optimizing.
Mine is 10% faster or slower because of that? I've lost track of which is faster now.
Yours was faster. I think my implementation of the do_comparison functions for one_junction, n_junction, injunction and abjunction are the reason.
Well, I'm still using separate loops. We can consider performance later.
The operators with the highest precedence we can use are "*" "/" "%".... I think "/" would look fine: all_of( a ) /expr()/ any_of(b). But there is a little problem with lambdas expressions using this operators. I tried following example: any_of( a ) |( lambda::_2 >= lambda::_1 )| all_of( b ). I got an error message from gcc 4.0.1 that the call to the second |-operator is ambiguous, because also lamda implements the | operator. How can this be
Too bad the parentheses weren't enough.
avoided? The only idea I have is the ","-operator. See below the error message.
All we're after is visual separation and decent interoperability. Lambda overrides all overridable operators, so I don't see how we can avoid the pain there. There are many operators from which to choose, but I think we should ensure we use one with higher precedence than the Boolean operators. Other than that, I think we just need an operator that is esthetically pleasing to a wide range of folks. Maybe we even need more than one!
Antoher point is the naming. I think, after reading a book about logic, that "junction" would be the best name.
In a private message, I mentioned that "junction" or "junctor" is appropriate only if what we're designing provides most everything those names imply. The other thing to consider is whether those names are meaningful to most folks. I know I wouldn't expect a "junction" library to do what we're talking about. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;