std::bitset woes

just store how much bits u want with the vector class in your own class.
or make a vector of bools but that is 8 times bigger as it has to be

Would it be possible to format the output using ignore (or similar) to eat the first n bytes?
ie:

Code:

---

std::cout << std::cin.ignore((32 - codelist[i].length))
          << std::bitset<32>(codelist[i].code)
          << std::endl; // doesn't work

---

Quote:

---

Originally Posted by grahamr (work)

Apparently you can't construct a bitset without a constant value in the constructor and I was wondering if there was a way around that:

Example:

Code:

---

                std::cout << std::bitset<50>(123456789) << std::endl;  // legal
                size_t bits = 50;
                std::cout << std::bitset<bits>(123456789) << std::endl; // illegal

---

Not being able to create a bitset with a variable makes it near useless.

---

Just wanted to clarify that in the illegal line of code you are not "constructing a bitset with a constant value in the constructor" here. You need to pass a constant into the template (that's what the value is between the '<' and '>'), so that the compiler can create the concrete bitset class for you. All templates need this kind of compile time information, however in most templates this information is a data type.

Viggy

I realised after posting that templates are compiletime not runtime - it's easy to forget sometimes.

A dynamic bitset would be extremely useful. Unfortunately by the time the C++ Standards committee gets around to ratifying C++0x and the major vendors get around to supporting it we'll be edging towards 2010:-(

And a quick look down the C++0x list of features they looking to support I didn't see dynamic bitsets.

G.

Quote:

---

Originally Posted by Mitsukai

just store how much bits u want with the vector class in your own class.
or make a vector of bools but that is 8 times bigger as it has to be

---

AFAIK Most implementations of vector<bool> use an optimal space (which implies that vector<bool> is not a container).
Which means that you can't optimize for space except using compression algorithms, but compressions algorithms, in the general case, can't make you gain space.

So, I suggest you use vector<bool> since each bool use 1 bit on usual implementations.

I was going to start a new thread on use of vector<bool> versus other methods but since it was brought up here and is related I will continue.

Is vector<bool> still not deprecated?

I know there are articles warning against it's use (Meyers/Sutter) and that it breaks container & iterator rules but while I am aware of these facts I can see a solid use for the type.

As mentioned I am writing a huffman encoder. I can see several possible routes for storing of the bitstream while it is being constructed:
1) Store the bitstream as vector<bool> or
2) as vector<unsigned char> or
3) Create a class called bitstream that will allow me to pop and push bits and handle everything in the background. Because random access isn't necessary this could be based on a queue rather than a vector.

Because I will need eventual access to the stream as-is I am leaning towards 2 & 3.

Thanks, Graham Reeds.

A possible scenario is creating your own Bitstream class, but implemented in a simple manner, based on std::vector<bool> class. For example, derive it from private std::vector<bool>, or have a member of std::vector<bool> type.

I think it will work fine, since you probably are not going to use some specific features, like iterators, not fully supported by std::vector<bool>. I suppose such operations, like push_back or [ ], offered by std::vector<bool>, are enough.

If some day you will be presumptively convinced that this approach is not good (for instance it is not quick enough), then re-implement it without changing the interface.

I hope this makes sense.