Re: [boost] [dynamic_bitset] Comparison operators without assertions

Subject: Re: [boost] [dynamic_bitset] Comparison operators without assertions
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-05-15 20:50:49

On 5/11/2017 1:34 AM, degski via Boost wrote:
> On 11 May 2017 at 08:11, Edward Diener via Boost <boost_at_[hidden]>
> wrote:
> 
>> There is no reason to change the right-to-left order as the most
>> significant bit is on the right.
> 
> 
> A bitset is not a number, 'most signifcant' depends on usage and is in the
> eye of the beholder.
> 
> 
>> Furthermore it would be foolish to break backward compatibility on a whim.
> 
> 
>   Yes.
> 
> I will probably keep the same order but just add that the longer size, the
>> rest being equal, will always be considered greater than the shorter size.
> 
> 
> One could introduce a comparison-policy, the default preserving the
> 'current' behaviour.
> 
> 
>> The only other possibility that I can imagine, if the assert is
>> eliminated, is to throw some exception if the sizes are not equal, which at
>> least has the possibility of keeping the program running if the exception
>> is caught.
>>
> 
> An exception seems completely wrong to me, as there is a valid use case for
> comparing bitsets of differing lengths. Exceptions should be used for
> exceptional situations, i.e. not here.

What I have ended up doing is to keep the exact same behavior as before 
when the bitsets are of equal size. When the bitsets are of unequal 
size, if either size is 0 that bitset is less than the other one. If 
neither size is 0 I convert both bitsets to an unsigned long using the 
already provided member function to_ulong() and use those values for the 
comparison.

I have tested this out adding some tests for different sized bitsets. I 
have not pushed this to 'develop' yet. I wanted to post here my solution 
and then others could chime in if they wished.

I found that it was completely wrong to do bit-by-bit comparisons when 
the bitsets were not the same size. No matter how I decided to do it the 
result was never correct. If anyone doubts this they can try it for 
themselves.

> 
> degski
>