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-09 19:16:20

On 5/9/2017 2:41 PM, Matt Calabrese via Boost wrote:
> On Wed, May 3, 2017 at 4:47 PM, Edward Diener via Boost <
> boost_at_[hidden]> wrote:
>>
>> I do not see the point of having <.<=,>, or >= for dynamic bitsets. I was
>> not involved in the original discussion about what this was supposed to
>> mean for dynamic_bitset but I would rather that they had not been
>> implemented at all. Given that they were implemented, and I have no idea
>> when that functionality would ever be used, I have no great stake in how
>> they should work when the bitsets are of different sizes. I do agree with
>> your point that using an assert when the bitsets are of different sizes is
>> a very poor solution.
> 
> 
> There are at least some advocates for defining these all of the time to
> represent a default order. If you don't fall into that camp, there is the
> existing precedent being that standard containers provide such operations,
> although they are technically only considered "optional requirements" for
> the standard container concept, even though that's a bit of an oxymoron.
> 
> On Wed, May 3, 2017 at 4:47 PM, Edward Diener via Boost <
> boost_at_[hidden]> wrote:
> 
>> I admit that I am baffled by the fact that, other than wanting to know if
>> two bitsets are equal or unequal, any sort of lesser or greater type
>> comparison makes any sense at all. But given that it is already implemented
>> in dynamic_bitset I am certainly not against a change which would work with
>> bitsets of different sizes.
> 
> 
> Having an ordering is a common requirement for generic
> algorithms/datastructures. Stepanov defines Regular types as including a
> default order. Since we don't (yet) have a standard way to specify some
> kind of default order that is different from the relational operators, that
> usually means overloading <, >, <=, and >=. I personally tend to feel that
> because a given type has multiple valid orderings, unless it's a monostate
> type, it's a questionable requirement. An ordering can always be specified
> at a call-site. Still, existing practice is to simply define the relational
> operators and I don't think it hurts.

I am more pragmatic in this case. Ordering is great when it means 
something. i just don't see that ordering dynamic_bitsets mean anything 
as far as the uses of a bitset are defined.

Given that there is an ordering I agree with the OP that an assertion, 
when bitsets are a different size and an ordering operator is used, is 
not the right way that dynamic_bitset should have been designed. But 
what should be done I do not know and am perfectly willing to defer to 
others on this, as I am just a maintainer and not the original developer.

>