On Feb 1, 2007, at 7:03 AM, François Duranleau wrote:
On Wed, 31 Jan 2007, Art Stamness wrote:
On Jan 31, 2007, at 4:21 PM, me22 wrote:
On 1/31/07, Art Stamness <artstamness@yahoo.com> wrote:
However, what's the main advantage of your code over Boost.Dynamic_Bitset and std::bitset? It seems (from a quick look) that your bit_array is close to std::bitset and your bit_vector is close to at least one of dynamic_bitset and vector<bool> (the latter being specialised for packing).
True, these types are similar to the std::bitset / boost::dynamic_bitset / std::vector<bool> in that they are used to represent bit data. However they have a very different operational semantic. These types are intended to model bit containers for arbitrary logic functions. Things that are commonly found when modeling hardware systems ( you can find why i do this under the "Motivation" section ).
For instance, taking 4 bits from one type and 4 bits from another, doing a logical exclusive-or on those bits, and placing it in 4 bits of a third type is a 1 line operation.
c.select(15,12) = a.select(7,4) ^ b.select(3,0) ; // a,b,c can all be bit_array / bit_vector / bit_container ( adapted type )
This very closely mimics what is found in hardware description languages ( which is my background ) .
c[15:12] = a[7:4] ^ b[3:0] ; // Same operation in Verilog
This library is intended to provide fixed , and resizable types, that can be used to model n-bit long logical operations in a clear semantic description, while also providing some STL container like interface for use with STL algorithm.
The above listed operations would be very difficult to do with any of the 3 listed types.
How about writing bit container algorithms instead of new bit containers? Taking the 'select' example, we could write:
select(c,15,12) = select(a,7,4) ^ select(b,3.0)
The 'select' algorithm would return a view for a range of bits. Thus we would only need to write those algorithms plus some view classes, and it could work with any already existing bit containers. It could be possible to specialize the views for certain types of containers if it could optimize some operations (I don't know).
This was a consideration. The problem is that I cannot create a "3- bit type", in any of the existing bit storage types ( uint8_t for example ) and still check for errors if the 4th bit is used. I wanted a strongly typed container system. The bit_container_adaptor class ( not documented, err well ) allows for taking any existing bit storage type, and providing the bit container functions. This will automatically size to the actual bit count of the container. so every data type would be a 2^n sized. That is not to say that adding select_bits as a free function isn't a good idea. Let me add that now ( the base functionality is there, it just does not exist as a function today ) . Thanks for the feedback. -Art p.s. Cromwell and Chris, I am working on providing responses to your earlier questions / comments.