Re: [boost] set arithmetic proposal

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-06-02 10:55:50

At 07:37 2005-06-02, christopher diggins wrote:
>----- Original Message ----- From: "Victor A. Wagner Jr." <vawjr_at_[hidden]>

[deleted]

>>I argued (unsuccessfully) that when the boost::dynamic_bitset<> was 
>>proposed that the _least_ we could do would be to fix the 
>>mis-characterization of operators <= and >= with regards to sets (for 
>>those who haven't studied sets,    {b,c,d} <= {a,b,c,d}  but that's not 
>>how it will evaluate with either std::set or boost::dynamic_bitset). 
>>Absent that oddity, I suspect that you could rather easily overload some 
>>global operators to handle what you want using any of std::set, 
>>std::bitset, or boost::dynamic_bitset (the backwardness of the comparison 
>>operators would still bother me, though).  Hmmmm, maybe I should look 
>>more closely at the "unordered collections" (hash_set) proposal further 
>>and see if that correctly manages the set concept.
>
>It might be very interesting to also overload comma to return sets, thus 
>allowing:
>
>namespace true_sets
>{
>  assert((1, 2, 3) + (4, 5) < (1,2,3,4,5,6)}

iirc, Pascal only allowed <= (subset).  I altered our compiler/library to 
allow a < b to mean    a <= b and a <> b  (it seemed reasonable at the time 
(still does)).
a <= b was defined as     (!(a - b) = [])        (for non Pascalers,  [] 
was the empty set constant)

>  assert((1, 2) == (2, 1)}
>  assert(range(1, 3) == (2, 1, 3)}

I'm not sure how you're going to get the compiler to recognize (1, 2, 3) as 
being the type (this_new_set), isn't that going to suffer from the same 
problem that we have now with things like   std::string abcdef = "abc" + 
"def";  ??

>}
>
>
>-Christopher Diggins

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law"