On Wednesday, March 8, 2017 at 7:44:56 AM UTC-5, V= icente J. Botet Escriba wrote:

=20 =20 =20

Le 08/03/2017 =C3=A0 06:23, 3dw...@verizon.net a =C3=A9crit=C2=A0:

On Tuesday, February 21, 2017 at 3:40:00 PM UTC-5, ricky6565 wrote:

Hi Vicente,

I think the Bitset2 library by Claas Bontus provide= s what you are looking for. It's like std::bitset but wit= h enhanced functionality. It let's you set the underlying integral type of the bitset. In fact, it=C2=A0defaults to uint8_t, uint16_t, or uint32_t=C2=A0if N=C2=A0bits fit = into those integers.=C2=A0I would like this functionality add= ed to std::bitset but, as you said, it would probably be a breaking change.

Riccardo

I was just thinking something similar.=C2=A0 Allow the user to specify the bitset leaf-type:

template<typename LeafTp =3D unsigned long long, std::size_t Bits =3D std::numeric_limits<LeafTp>::digits><= /span> =C2=A0 class bit_array =C2=A0 { =C2=A0 =C2=A0 // pretty= much like bitset except I would add =C2=A0 =C2=A0 using leaf_type =3D LeafTp; =C2=A0 =C2=A0 leaf_iterator lbegin() // =C2=A0 =C2=A0 leaf_iterator lend(); // =C2=A0 };

This is flipped relative to Bitset2 in that leaf type comes first and the template would decide how many leaves based on bits.

So now you could get these small bitsets:
using bitset16 =3D bit_array<uint16_t>;
etc.

I believe that both orders could have have usage (see below), an alias templates should help here to have both.
However I don't like the possibility to have bit_array<>. How many bits do we have?

In this case bit_a= rray<> is bit_array<unsigned long long, std::numeric_limits<uns= igned long long>::digits>
so on my system, 64-bits.=C2=A0 Perhaps = we want a fixed size integral type as the default type.
We could also no= t a a default type.

=C2=A0

If the data function returns a span<T,N> we don't need the leaf iterator functions.

=C2=A0
This is good.=C2=A0 My one worry was that my AP= I was getting baroque with both vector and bitset access.

I've heard people want similar choices fo= r a dynamic_bitset:

template<typename LeafTp =3D unsigned long long> =C2=A0 class bit_vector =C2=A0 { =C2=A0 =C2=A0 // pretty= much like bitset except I would add =C2=A0 =C2=A0 using leaf_type =3D LeafTp; =C2=A0 =C2=A0 leaf_iterator lbegin() // =C2=A0 =C2=A0 leaf_iterator lend(); // =C2=A0 };

People who do encryption wanted to set the size of the leaf and have access to leaves.
I chose bit_arr= ay and bit_vector<= /span> to have a similar relationship as array and vector do.

For the names I believe we should stay close to bitset and dynamic_bitset. But we can not use bitset :(
I need to think more about your bit_array/bit_vector suggestion, but array/vector don't have set operations. I will go towards bit_set and dynamic_bit_set.
In addition bit_array<int16_t, 10> could be misleading as array<int16_t, 10> has a completely different meaning and layout. Do we have 10 int16_t?

We could bikeshed for ever ;-)=C2= =A0 Maybe bitvec and dynamic_bitvec?
I see your point about confusion th= ough.

I could almost see a reason for a UDL bits, and bytes.=C2=A0 A= PIs could take either.
They would not convert to ints automatical= ly.=C2=A0 APIs taking number of elements (array, vector, ...) would remain = unchanged.
This is almost like <units>.
But numeric and bitset = types would be able to take bits and bytes.=C2=A0 These UDLs would return b= it_size_t and byte_size_t that could inter-convert between each other but n= ot to integers without a to_size_t() or something.
This might help the f= ixed_point people and bit utility.=C2=A0 Or it might annoy them.

Vicente