The vector_max_size_workaround() we had in place, and one of the test
cases, only considered std::vectors, which are no longer the only
allowed containers. This commit fixes "Allow choosing the underlying
container type".
We were using `AllocatorOrContainer` as if it were still guaranteed to
be an allocator type. Unfortunately, the append() tests didn't exercise
input iterators, so this went unnoticed. I've now added tests.
This is in preparation of the next commit, which will add a constructor
from std::basic_string_view (otherwise, construction from a C-style
string would be ambiguous between the basic_string_view and the
basic_string constructor).
Note that, rather than duplicating code to test the new member, we
changed many constructions in dyn_bitset_unit_tests1.cpp to use const
char *, instead of std::string. (The constructor from std::basic_string
is tested separately anyway.)
The user can now choose the underlying container type used by
dynamic_bitset. This allows e.g. having small buffer optimization by
using boost::container::small_vector.
Since the underlying container is no longer guaranteed to be
std::vector, we revert "Reflect some noexcept specifications of
std::vector in dynamic_bitset" and the related "Let MrDocs compile the
code as C++17".
Note that we didn't add serialization tests (dyn_bitset_unit_tests5.cpp)
because boost::container::small_vector has no serialization support.
This closes issue #76.
This commit:
- Sorts the #include directives: The #includes of the ""-form come
first, those of the <>-form come later (this helps checking if any
include file is not self-sufficient); in each of the two groups, the
names of the headers or source files are sorted alphabetically (this
eases searching for a specific #include and avoids duplicates).
- Uses the ""-form when including Boost files; using the <>-form is a
relic of the past. This was even discussed on the developers list many
years ago and led to core issue 370. Note that some parts of
DynamicBitset were already using the ""-form and that has never caused
any problem, AFAIK.
- Removes some comments attached to the directives themselves which
seemed pretty useless and prone to get out of sync.
It is better to support copy-initialization with default constructor. cf. LWG Issue 2193. Default constructors for standard library containers are explicit.
