[...]
I got that book recently, but I haven't read it yet. I just read his discussion of safe bool to be sure I knew to what you were referring. The complexity is worthwhile, though it needn't be as complex as his solution
I found some simpler solutions, while searching the net. But this is an implementation detail, what we wanted to discuss later. It's on my memo.
It's interesting to note that his use of the generator class is erroneous until he puts in a "workaround" for Borland. On p404, he's still using "typedef boolean_type::return_type," but "return_type" is a dependent type, so standard C++ requires "typename" so his "workaround" was to make the code correct!
I didn't noticed that. This is a good reason to send him a mail to correct this in the next edition of his book or at least to add a comment why he did it so. I don't remember every datail. I will read this chapter a second time, before I go to bed tonight. ;-)
We have a fundamental disconnect that we must resolve. If there is or should be more to junctions than I've mentioned, I need to understand the use cases and rationale. It may also be that you're trying to combine different concepts into the same set of classes and we should tease them apart.
Maybe I'am. Perl 6 has a lot of new features, that I didn't know and I'am more influenced by this Quantum::Superpositions module. You can download it from http://www.cpan.org/modules/by-module/Quantum/Quantum-Superpositions-2.02.ta... an take a look at the manual page. [...]
In the Quantum::Superpositions module manual page are examples to get the min/max of a list in one line of code, which is based on the resulting junction of a comparison:
Minimum of a : any_of( a ) <= all_of( a ) Maximum of a : any_of( a ) >= all_of( a )
That's supported by my equality operator approach, too.
I doesn't see that, or I didn't unserstand something. Because the resulting junction of any_of( a ) <= all_of( a ) contains the minimum value of a. Probaly there are more expressions like this, where the resulting junction contains values which are useful. That's why I like to have a result junction besides the boolean result value. For example "a" contains 1, 2, 3 then the resulting junction of any_of( a ) >= all_of( a ) contains 3, which is the maximum value of a. [...]
I don't know what you mean by "adhere to the duality of the result of a comparison" unless you mean that your version always returns a new junction that can implicitly convert to a Boolean for comparisons. I don't see the value of that.
See above.
[...]
disjunction< Container > a, b;
disjunction< Container > r = a <= b; // assign to another junction
[...]
Container r_c = a <= b; // use values of the resulting junction ( if junctions are refs, then this isn't necessary )
Why?
See above. At least one of them is useful. Returning a new junction as result would make possible to write something like this: ( any_of( a ) >= any_of( b ) ) <= any_of( c ) Or if the comparison returns an container: any_of( any_of( a ) >= any_of( b ) ) <= any_of( c )
If we can agree to forgo the arithmetic functionality you've thought should be part of the junction classes, we can simplify the design significantly. That, in turn, will make writing documentation easier and will increase the chances of acceptance into Boost.
Ok, let's forget the arithmetic functionality. You're right, that I was trying to combine more than one concept. That was the influence of Perl and this Quantum::Superpositions module. ;-) Florian