Codecov Report

Merging #27 into develop will increase coverage by 1.35%.
The diff coverage is 90.56%.

@@             Coverage Diff             @@
##           develop      #27      +/-   ##
===========================================
+ Coverage    75.41%   76.76%   +1.35%     
===========================================
  Files            5        5              
  Lines          541      594      +53     
  Branches       198      210      +12     
===========================================
+ Hits           408      456      +48     
- Misses          23       24       +1     
- Partials       110      114       +4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b944aa3...f536fcd. Read the comment docs.

This change is fine, however I think calling it set() makes more sense, and adding reset(f, l) and perhaps flip(f, l) so that all the bit manipulators can operate either on a single bit or a range of bits would complete the desired goal to modify sequences efficiently. As for the meaning of last as you discussed, I'm wondering if first_bit, num_bits makes sense instead of first_bit, last_bit. Then all instantiations of set forward to one implementation that would hopefully be optimal for all cases: set() -> set(0, num_bits), and set(bit) -> set(bit, 1). Just a thought - not sure it would work out that way but worth thinking about.

@jeking3 I like your thoughts and agree with most of them.

Using relative last bit positions instead of absolute is done in std::string and it's logical to do the same here.

I decided to not call set(bit) -> set(but, 1) and similar, because the common case (any borders) takes some calculations and is more slower than just changing a bit, or setting all the bits to 1. Moreover current set functions are tiny.

But I have a serious doubt connected with implicit conversions from int to bool.
If a programmer paid no attention to warnings and/or had to code really fast, he could write this:

int okay = 42;
/* Transforming 'okay' */
db.set(pos, okay);

The last line was supposed to be db.set(pos, okay != 0) according to the current state, but having a new function dynamic_bitset& set(size_t n, size_t len, bool value = true) makes it into db.set(pos, okay, true) implicitly, which seems to me a serious thing...

Other things seem fine to me, I'd make reset() and flip() with tests as well, after some time.

So, I've added some commits and there are three new range functions... With tests, docs, without code doubling. Anyone, feel free to comment them!