Re: [boost] Interest for a perl6-like-junctions-class?
I uploaded some fixes to multivalues.zip: - Workaround for BCB's lack of EBO - Fixed some overzealous searches/replaces - Eliminated SFINAE from test program - Moved some tests out of the macros to assist in debugging, should anyone have problems with support in a particular compiler. Some questions: - What operator(s) should we use to delimit user-defined predicates? Here are some interesting candidates: if (any_of(...) << some_predicate() >> 5)... // 1 if (any_of(...) < some_predicate() > 5)... // 2 if (any_of(...) ^ some_predicate() ^ 5)... // 3 if (any_of(...) / some_predicate() / 5)... // 4 1 seems pretty good because the two-character operators stand out well. 2 works pretty well, but I'm concerned that the operators may get lost if the predicate is a specialization of a template type; the template argument list uses the same tokens. (1 is better in that case because of the doubled tokens.) 3 is an unusual operator to overload, so it is largely unique to this context. 4 works, but I'm concerned that it is gross misuse of the operator (overloading it for division and filesystem path manipulation are sensible; is this?). - Should we attempt VC6 support? If so, some functionality or syntax will have to be sacrificed. It may be that the iterator pair support is all that we must sacrifice. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
I uploaded some fixes to multivalues.zip:
- Workaround for BCB's lack of EBO
- Fixed some overzealous searches/replaces
- Eliminated SFINAE from test program
- Moved some tests out of the macros to assist in debugging, should anyone have problems with support in a particular compiler.
Some questions:
- What operator(s) should we use to delimit user-defined predicates? Here are some interesting candidates:
if (any_of(...) << some_predicate() >> 5)... // 1
if (any_of(...) < some_predicate() > 5)... // 2
if (any_of(...) ^ some_predicate() ^ 5)... // 3
if (any_of(...) / some_predicate() / 5)... // 4
1 seems pretty good because the two-character operators stand out well. 2 works pretty well, but I'm concerned that the operators may get lost if the predicate is a specialization of a template type; the template argument list uses the same tokens. (1 is better in that case because of the doubled tokens.)
None of them look right to me. Unless you close up the spaces next to some_predicate(), they appear to be doing what the usual C++ operators do. a < b looks like less-than; a <b immediately starts to suggest something else. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
if (any_of(...) << some_predicate() >> 5)... // 1
if (any_of(...) < some_predicate() > 5)... // 2
if (any_of(...) ^ some_predicate() ^ 5)... // 3
if (any_of(...) / some_predicate() / 5)... // 4
1 seems pretty good because the two-character operators stand out well. 2 works pretty well, but I'm concerned that the operators may get lost if the predicate is a specialization of a template type; the template argument list uses the same tokens. (1 is better in that case because of the doubled tokens.)
None of them look right to me. Unless you close up the spaces next to some_predicate(), they appear to be doing what the usual C++ operators do. a < b looks like less-than; a <b immediately starts to suggest something else.
You can omit spaces to make it look right to you. I dislike omitting spaces around operators. So, without the internal spaces, do you like any of them? if (any_of(...) <<some_predicate()>> 5)... // 1 if (any_of(...) <some_predicate()> 5)... // 2 if (any_of(...) ^some_predicate()^ 5)... // 3 if (any_of(...) /some_predicate()/ 5)... // 4 -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
You can omit spaces to make it look right to you. I dislike omitting spaces around operators. So, without the internal spaces, do you like any of them?
if (any_of(...) <<some_predicate()>> 5)... // 1
if (any_of(...) <some_predicate()> 5)... // 2
if (any_of(...) ^some_predicate()^ 5)... // 3
if (any_of(...) /some_predicate()/ 5)... // 4
Not with the parens in there. What's that for? Are you assuming some_predicate is the type of a stateless function object? if (any_of(...) <<some_predicate>> 5)... // 1 if (any_of(...) <some_predicate> 5)... // 2 if (any_of(...) ^some_predicate^ 5)... // 3 if (any_of(...) /some_predicate/ 5)... // 4 That's a little better. I guess any of them but the last looks okay. Have you considered how/whether operator precedence will affect the usability of these? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rob Stewart <stewart@sig.com> writes:
Not with the parens in there. What's that for? Are you assuming some_predicate is the type of a stateless function object?
if (any_of(...) <<some_predicate>> 5)... // 1
if (any_of(...) <some_predicate> 5)... // 2
if (any_of(...) ^some_predicate^ 5)... // 3
if (any_of(...) /some_predicate/ 5)... // 4
That's a little better. I guess any of them but the last looks okay.
Have you considered how/whether operator precedence will affect the usability of these?
Yes we have done that in a private discussion. I think the minumum precendence must be higher than the &&, || operators. So that expressions like any_of( a ) <<pred()>> all_of( b ) && any_of( c ) < all_of( d ) are interpreted correct. Florian.
David Abrahams wrote:
Rob Stewart <stewart@sig.com> writes:
1 seems pretty good because the two-character operators stand out well. 2 works pretty well, but I'm concerned that the operators may get lost if the predicate is a specialization of a template type; the template argument list uses the same tokens. (1 is better in that case because of the doubled tokens.)
None of them look right to me. Unless you close up the spaces next to some_predicate(), they appear to be doing what the usual C++ operators do. a < b looks like less-than; a <b immediately starts to suggest something else.
Hmm.. << >> would be look ok for me, because multivalues don´t provide arithmetic operations and they can't be misunderstood in this context. But at all, I don´t like this misuse of operator overloads, because it can lead into complex and confusing compiler error messages. My appraoch is still to provide a simple predicate-function like compare( all_off( a ), pred(), any_of( b ) ). This has also the advantage, that there are no ambigous problems with operator overloads of lambda expressions, which occour if you write something like all_of( a ) << lambda::_1 > lambda::_2 >> any_of( b ).. Where also parentheses don't help. Sincerely Florian
Florian wrote:
Hmm.. << >> would be look ok for me, because multivalues don´t provide arithmetic operations and they can't be misunderstood in this context. But at all, I don´t like this misuse of operator overloads, ...
I feel the same; none of the proposals are good, and user-defined predicates are probably rare enough that the below compare() idea is fine. Darren
because it can lead into complex and confusing compiler error messages. My appraoch is still to provide a simple predicate-function like compare( all_off( a ), pred(), any_of( b ) ). This has also the advantage, that there are no ambigous problems with operator overloads of lambda expressions, which occour if you write something like all_of( a ) << lambda::_1 > lambda::_2 >> any_of( b ).. Where also parentheses don't help.
From: Darren Cook <darren@dcook.org>
Florian wrote:
Hmm.. << >> would be look ok for me, because multivalues donŽt provide arithmetic operations and they can't be misunderstood in this context. But at all, I donŽt like this misuse of operator overloads, ...
I feel the same; none of the proposals are good, and user-defined predicates are probably rare enough that the below compare() idea is fine.
I uploaded a new version of multivalues.zip that includes a test() function. I thought "test" sounded better than "compare" for general predicate tests: if (test(all_of(a), pred(), any_of(b)))... vs. if (compare(all_of(a), pred(), any_of(b)))... Let me know which you prefer or if you have a better idea. The ^ operator is still supported until there is some consensus on another operator or on supporting no operator. Another option is to provide support for several operators so one can choose whichever one likes best. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (1)
-
Darren Cook -
David Abrahams -
Florian Stegner -
Rob Stewart