2009/3/7 vicente.botet <vicente.botet@wanadoo.fr>:
----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com>
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