Re: [boost] [dynamic_bitset] intersects

Subject: Re: [boost] [dynamic_bitset] intersects
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2009-03-08 14:18:31

2009/3/7 vicente.botet <vicente.botet_at_[hidden]>:
> ----- Original Message -----
> From: "Steven Watanabe" <watanabesj_at_[hidden]>
>> vicente.botet wrote:
>>> I want to know if two dynamic_bitsets have an element in common. Is there an efficient way to get this?
>>>
>>> dynamic_bitset<> bs1, bs2;
>>>
>>> intersetcs(bs1, bs2)?
>>>
>>
>> It's a member function.
>> bs1.intersects(bs2);
>

I think that the assumption of Vicente ...

dynamic_bitset<> bs1, bs2;
// ... expecting ...
intersetcs(bs1, bs2)?

is kind of justified, because function intersects could be implemented
not only by memberfunctions of dynamic_bitset but even with non member
functions, in more than one way,

e.g.
bool intersects(const dynamic_bitset<Block, Allocator>& a,
               const dynamic_bitset<Block, Allocator>& b)
// nonmembers & and member empty()
{ return !(a & b).empty(); }

this would be consistent with the coding standard to keep class
interfaces minimal and to implement namespace global functions
on the bases of class memberfunctions where ever this is possible.

I've stumbled over this, because I took the pleasure to refactor the
interfaces of my libraries class interfaces according to that rule
recently and made the experience that this can reduce class
interfaces rather drastically up to a point that hurts ;)

Seeing this example in an established boost library raises the
question how serious this rule in taken in the boost community
or what the special reason might be to implement

intersects

as member function here.

Cheers
Joachim