我打算创建一个数字类。目的是保存任意数量的数字，而不用担心获得太多（例如 int 或 long）。但同时不要使用太多。例如：
如果我的数据实际上只需要 1-10，那么我不需要 int（4 字节）、short（2 字节）甚至 char（1 字节）。那么为什么要分配这么多呢？
如果我想保存需要极大数量的数据（在这种情况下只有整数），例如超过数十亿，我不能。
我的目标是创建一个数字类，可以像字符串一样处理这个问题，调整大小以适合数字。但在开始之前，我想知道..
bitset<1>，bitset是一个模板类，允许我在C++中对位进行最小化，非常有用，但是它高效吗？，bitset<1>会定义 1 位，但我想创建一个数组吗？ C++ 可以分配最小字节，bitset<1> 是否可以分配字节？分配一个字节并提供该字节的 1 位？如果是这样的话，我宁愿用 unsigned char* 创建我的数字类。
unsigned char，或 BYTE 保存 8 个字节，从 0 - 256 的任何数字都只需要一个，更多需要两个，然后是 3 个，当需要字节间隔而不是位间隔时，它会简单地继续扩展。
你认为哪个更有效？，如果 bitset 实际上分配了 1 位，那么这些位将是，但我有一种感觉，这甚至是不可能的。事实上，在 32 位处理器上，以字节为单位进行分配实际上可能更有效，直到 4 个字节（32 位），32 位分配是最有效的，因此从那时起我将一次使用 4 个字节。
基本上我的问题是，你的想法是什么？我应该如何处理这个实现，bitset<1>，或unsigned char（或BYTE）？
I'm planning on creating a number class. The purpose is to hold any amount of numbers without worrying about getting too much (like with int, or long). But at the same time not USING too much. For example:
If I have data that only really needs 1-10, I don't need a int (4 bytes), a short(2 bytes) or even a char(1 byte). So why allocate so much?
If i want to hold data that requires an extremely large amount (only integers in this scenario) like past the billions, I cannot.
My goal is to create a number class that can handle this problem like strings do, sizing to fit the number. But before I begin, I was wondering..
bitset<1>, bitset is a template class that allows me to minipulate bits in C++, quite useful, but is it efficient?, bitset<1> would define 1 bit, but do I want to make an array of them? C++ can allocate a byte minimum, does bitset<1> allocate a byte and provide 1 bit OF that byte? if thats the case I'd rather create my number class with unsigned char*'s.
unsigned char, or BYTE holds 8 bytes, anything from 0 - 256 would only need one, more would require two, then 3, it would simply keep expanding when needed in byte intervals rather than bit intervals.
Which do you think is MORE efficient?, the bits would be if bitset actually allocated 1 bit, but I have a feeling that it isn't even possible. In fact, it may actually be more efficient to allocate in bytes until 4 bytes, (32 bits), on a 32 bit processor 32 bit allocation is most efficient thus I would use 4 bytes at a time from then on out.
Basically my question is, what are your thoughts? how should I go about this implementation, bitset<1>, or unsigned char (or BYTE)??
发布评论
评论（3）
除非您的目标架构是 DigiComp-1，否则优化位是愚蠢的。读取单个位总是比读取整数慢 - 4 位并不比 8 位更有效
。如果要将其存储为十进制数，请使用 unsigned char。这将是最有效的。
或者，您可以只使用 GMP。
Optimizing for bits is silly unless you're target architecture is a DigiComp-1. Reading individual bits is always slower than reading ints - 4 bits isn't more efficient than 8.
Use unsigned char if you want to store it as a decimal number. This will be the most efficient.
Or, you could just use GMP.
位集模板需要一个编译时 const 整数作为其模板参数。当您必须在运行时确定最大位大小时，这可能是一个缺点。另一件事是，大多数编译器/库使用
unsigned int或unsigned long long来存储位以加快内存访问速度。如果您的应用程序在内存有限的环境中运行，您应该创建一个新的类（如 bitset）或使用不同的库。The bitset template requires a compile-time const integer for its template argument. This could be a drawback when you have to determine the max bits size at run-time. Another thing is that most of the compilers / libraries use
unsigned intorunsigned long longto store the bits for faster memory access. If your application would run in a environment with limited memory, you should create a new class like bitset or use a different library.虽然它不会直接帮助您对巨数进行算术，但如果这种节省空间是您的目标，那么您可能会发现我的 Nstate 库很有用（增强许可证）：
http://hostilefork.com/nstate/
例如：如果您有一个介于 0 和 2 之间的值...那么只要您将将一堆这些存储在一个数组中，您可以利用未使用的第四状态 (3) 的“浪费”空间来打包更多值。在这种特殊情况下，您可以在 32 位字中获得 20 个三态，而不是每个三态 2 位获得 16 个三态。
While it won't directly help you with arithmetic on giant numbers, if this kind of space-saving is your goal then you might find my Nstate library useful (boost license):
http://hostilefork.com/nstate/
For instance: if you have a value that can be between 0 and 2...then so long as you are going to be storing a bunch of these in an array you can exploit the "wasted" space for the unused 4th state (3) to pack more values. In that particular case, you can get 20 tristates in a 32-bit word instead of the 16 that you would get with 2-bits per tristate.