I am wondering why std::bitset::reference
and std::vector<bool>::reference
specifies an explicit destructor (not compiler generated one). Because, for example, boost::dynamic_bitset::reference
does not seem to specify such a destructor.

- 57,703
- 61
- 205
- 388
-
8Someone wrote this up in the 1990's, and nobody has proposed to change it since? No other reason, I guess. – Bo Persson Dec 18 '15 at 16:14
1 Answers
Just because the Standard mentions ~reference()
as a destructor, does not mean it has to be user-provided as a no-op {}
(which is how libstdc++ and SGI/STL do it). It could also be user-declared as =default
, or even left defined implicitly (which is how libc++ does it). Regardless, the Standard could be updated to have this explicit mention of the destructor removed. You could file an editorial change (I don't think it warrants a real proposal).
As noted by @BoPersson in the comments, std::bitset
is a very old component of the Standard Library. Many of its features (implicit constructor from unsigned integer, member instead of non-member operator==
) pre-date the language standardization in 1998. Shameless plugs: see e.g. this Q&A for more discussion how this might have arisen, and this Q&A for why it might break code when this would be fixed.
<rant mode>
The best way out of the legacy of std::bitset
would be a clean break in namespace experimental
. Preferably, this would also solve the mixed abstraction of std::bitset
, which at the same time tries to be a space optimized version of array<bool>
as well as a set<int>
. Ideally, there would be a proposal for a bool_array<N>
and a bounded_int_set<N>
that provided these abstractions. Similarly, bool_vector<Alloc>
(currently known as vector<bool, Alloc>
) and int_set<Alloc>
(currently a mixture of boost::dynamic_bitset
and boost::container::flat_set<int, Alloc>
) could be defined.
</rant mode>

- 1
- 1

- 69,038
- 19
- 164
- 304