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

Subject: Re: [boost] [dynamic_bitset] Comparison operators without assertions
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2017-05-09 18:41:35

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.

-- 
-Matt Calabrese