unique data types

i'm in the need of a 1 byte data type.
i don't want to use 'char'.

heck, theoretically, could i make a 4bit type? ... 2bit?

what are my options?

Any class or struct you write creates a new datatype.

All new datatypes will be at least one byte.

Why don't you want to use char? If you want to keep your type separate from char you can wrap a class around a char. You can also use a typedef so your "type" has a different name, although in reality it will be the same type.

If you want to save space and only use 4 bits, you can't create a datatype to do it, but you might be able to use other storage options to get a similar effect.

You could use bit-fields, but those are nasty.

Just use unsigned char.

i don't want to do this, to store the value;

(unsigned char)( (short int) val )

i don't want to cast either, to just store a value in to an unnecessarily large data type.
on principle i'd like to make this as perfect as possible.
so if anyone else knows, tell me.

i'm going to look in to bit fields.


the code i'm writing requires three large arrays, when i initialize them with INT the app crashes. if i use the smallest necessary types it works fine.

at least until i scale the window large enough then it crashes anyway.

i have 2gb of memory and the usage never goes over 1gb, any explanations for that? i might be able to get around having to do this if i can figure that out.

or just char, since char is unsigned by default (whereas short, long, int, long long int/"the equivalent in microsoft world" are signed by default)

Quote:

---

the code i'm writing requires three large arrays, when i initialize them with INT the app crashes. if i use the smallest necessary types it works fine.

at least until i scale the window large enough then it crashes anyway.

---

that suggests poor design.

Can you post a bit more code so we know what are you trying to do?

Quote:

---

Originally Posted by cyberfish

that suggests poor design.

Can you post a bit more code so we know what are you trying to do?

---

alright, sure;

this is global;

Code:

---

const int
        AW = 512,
        AH = 384;

typedef struct RGB
{
        unsigned char r, g, b;
};

RGB Image[AW][AH];

---

this is in the render loop, but *only* executes if the window is scaled;

Code:

---

CW = glutGet(GLUT_WINDOW_WIDTH);
CH = glutGet(GLUT_WINDOW_HEIGHT);

RGB AImage[CW][AH];
RGB SImage[CW][CH];

---

if the RGB struct uses SHORT INT, merely initiating SImage crashes the app. (using unsigned char)

the app crashes anyway if the window is scaled beyond 800x600-ish.

>> char is unsigned by default
This isn't guaranteed. It depends on the implementation.

What range of values are possible for your numbers?

char is not unsigned by default on my machine.
i need to store values no larger than 255 for each of the three primary color components.

storing the three color components in to an int was unnecessary since it offered too much space.
just fyi in case anyone mentions it. and as i've said, too large of data types crashed my app.

I don't see how large data types can crash your app.
Even your "huge" array of RGB (even if you switch them out with ints instead of chars), would take about 2 MB of memory. Something else may be amiss.

800x600 * 4 bytes is still only about 1.92 MB, there should be plenty of heap space for that. It might cause you to run out of stack space. Perhaps you should use dynamic memory like a vector to hold the data.

Quote:

---

Originally Posted by Elysia

I don't see how large data types can crash your app.
Even your "huge" array of RGB (even if you switch them out with ints instead of chars), would take about 2 MB of memory. Something else may be amiss.

---

i've cut the application down to only the array initializations, and it crashes still in the same fashion i've described above.

Quote:

---

Originally Posted by Daved

800x600 * 4 bytes is still only about 1.92 MB, there should be plenty of heap space for that. It might cause you to run out of stack space. Perhaps you should use dynamic memory like a vector to hold the data.

---

hmm, you're right, i should use vectors since i'm writing c++.
i'll swap it up.

never mind! i forgot to change a couple things. the app doesn't crash anymore.

thanks for the heads up on the vectors daved.
and i guess i'll stick with unsigned chars.

Edit: Apparently the problem was solved by the removal of the stack based arrays.

Quote:

---

Originally Posted by simpleid

char is not unsigned by default on my machine.
i need to store values no larger than 255 for each of the three primary color components.

storing the three color components in to an int was unnecessary since it offered too much space.
just fyi in case anyone mentions it. and as i've said, too large of data types crashed my app.

---

If you need values up to 255, you can't use anything smaller than an unsigned char.

Also, you might want to do something like this:

Code:

---

typedef unsigned char  color;

---

That way, in the future if you decide you need more than 255 shades/color, it will be much easier to change. Plus it would make the meaning of your code clearer.

Don't create things that are larger than a few kB on the stack. You only have about 1 MB of stack space on most systems. Allocate such things from the heap.

Quote:

---

Originally Posted by simpleid

theoretically, could i make a 4bit type? ... 2bit?

---

You could do something along the lines of the vector<bool> specialisation to achieve such a thing. At last that's where I'd start if I were going to make that.

Quote:

---

theoretically, could i make a 4bit type? ... 2bit?

---

i would make a class that emulates a "collection" of such type, and use bitwise operations to implement operations on them. Note that it will be very inefficient though. For this particular case, just allocate the memory on the heap (new or malloc).

vector<bool> is evil, and very likely to be deprecated in the next standard.

Use std::bitset if you have a collection of known size, or boost::dynamic_bitset if it's of unknown size. But in this case, I agree with cyberfish.

I worked on a C++ project that simulated a complete chip, and it had, as part of the design, n-bit wide types from 1 to 512 bits. Although, as a space-saving excercise, it wouldn't be particularly useful, since each integer was a class, which takes up more than one byte [because to make it efficient, the class essentially had two fields, one to hold the value and one that was the mask whcih whcih to extract the actual value after any math operation].

--
Mats