Subject: Re: [boost] [dynamic_bitset] Comparison operators without assertions
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2017-04-30 16:22:01
On Apr 27, 2017 13:36, "Pavel Kretov via Boost" <boost_at_[hidden]>
Looking through boost::dynamic_bitset code, I found a interesting
inconsistency between its operator== and operator<. Namely, the first
works well with bitsets of different size, while the second triggers
a == b; // false
a < b; // Assertion `a.size() == b.size()' failed.
This means that we cannot reliably use dynamic bitset within ordered
containers like std::set or std::map.
Since the standard library has distinct concepts of equality and
equivalence (see ), it's fine to have different comparison
behaviors in dynamic_bitset. However, as far as I can judge,
equivalence is a metaphysically broader concept than equality, we
shouldn't restrict it to bitsets of the same size only.
So, the questions:
1. May I remove that assertion?
(It won't be a breaking change, after all).
I agree that such comparisons should be valid. We should represent a total
order, just like standard containers do (assuming their elements do, of
course). I'm actually rather surprised that this isn't already supported.
On Apr 27, 2017 13:36, "Pavel Kretov via Boost"
2. How about doing the same thing to bitwise operators, too? Instead
of throwing an assertion if sizes don't match, it may be worth to
generalize the operators definitions. I can see several possible
schemes, but not all of them are consistent enough.
I'm not sure, though I agree that it's definitely worth investigating with
further discussion on the list and some example use-cases. I intuitively
suspect it's a reasonable generalization to act as though implicit 0s were
present for the shorter operand, based on an interpretation as a binary
value. The side on which to pad should be consistent with the
lexicographical ordering. Even this generalization is somewhat debatable
though, since extraneous 0s contribute to value in a dynamic bitset.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk