I have two arrays of UINT32's that look like this.
I'm using them to store bits. Here's my problem.
Let's imagine both a and b have 48 bits stored in them, so they both have size()==2. But only half of the second UINT32 is actually being used as bits. I need to insert b onto a, but I want to insert it on the bit level. So after the insertion is complete the result should be size()==3 and 96 bits total. The bits must also stay in the same order as they are in currently, so no swapping. The problem is that I have no idea how to do this, but it seems like there must be a way. If anybody needs clarification on anything just ask.
why would you want to thwart the idea of container classes by bypassing their access methods?
I believe I have actually found my solution in Guru Of The Week 72.
The way I'm looking at it I need to. I'm only using vector for its memory management help. If I were to use vector<UINT32>::Insert to add b to a there would be 16 bits between left unused.
edit: It looks like I'm going to end up using vector<bool> or bitset though.
edit2: make that vector<bool>
edit3: make that dynamic_bitset
i'm sure laserlight, et al. will disagree, but to me it seems easier to use char * and do the memory management yourself imho.
It is not. Especially not when vector<bool> does it all for you. You think like a C programmer. What are you doing here? :p
Isn't vector<bool> deprecated?
dynamic_bitset (boost has one but is it going to make into C++0x?) seems like a good choice.
Originally Posted by Elysia
This seems to miss a lot of functionality that you'd expect from a bitset (most notably copy constructor and assignment operator). See here for what boost::dynamic_bitset has. Then think if you want to implement all that all over.
Your implementation also suffers from a number of problems, such as mixing realloc and delete (and using realloc in an unrecommended way - and reduplicating code that does reallocing). And what's with the C-style casts to T*. Any good coming if T happens to be something like std::string? And it isn't really a bitbuffer, as it appears to use one byte per bit.
yeah, true. it was more an example of how i thought the problem could be tackled much more simply than that GOTW page. but i shouldn't post things that aren't totally correct, especially if i'm not really interested in doing it correctly to a T (pun intended).
and despite my unfortunate naming, it wasn't necessarily a bitbuffer so much as it was directed at the OP's problem.