On 4 Sep 2025 18:22, Gennaro Prota via Boost wrote:
On 9/4/2025 11:33 AM, Gennaro Prota wrote: [...]
2. A function similar to find_first, but for locating the first "off" bit.
Hmm... I'll implement that. Thanks for the suggestion :-).
I'm thinking of a way to avoid introducing a new member function for that. Adding a (defaulted) bool parameter to the existing find_first()'s, like this:
size_type find_first( bool value = true ) const; size_type find_first( size_type pos, bool value = true ) const;
would make a call like b.find_first( 1 ) ambiguous. An idea could be:
enum class bit_value { set, unset };
size_type find_first( bit_value value = bit_value::set ) const; size_type find_first( size_type pos, bit_value value = bit_value::set ) const;
but that would be inconsistent with the rest of the library.
Using an argument makes sense when there are use cases when the parameter value is obtained at run time. Then the parameter allows the user to avoid spelling out the branch. My impression is that this is not the case. You almost always know at compile time which behavior you want, as this is usually part of the higher level algorithm. It would make sense to have different names for different operations in this case. Furthermore, find_first (zero or one) is typically implemented using a dedicated CPU instruction, possibly in a loop. I think, such CPU instructions implement only one search (again, either zero or one). If you add the parameter, you would be introducing a branch which would otherwise be not needed. So, my preference would be separate methods.