Enums and pointers... likelihood of end of space memory

[primem0ver]

I have a situation where I have a "list" class that represents a set of possible values for a custom user control type that goes on a menu. The point is so that "mod" developers can define standard sets of values that a user can toggle through which will have custom icons, values, and text for each value. (Think of it as a way for a mod developer to have an enum of values for a specific control)

There are also generic sets defined internally in the program. What is the danger that using an enum of negative values will cause a problem? Here are the possible values:

enum GenericStateSetType 
{ 
	NotUsed = 0, 
	Bullet = -1, //0xFFFFFFFF
	Check = -2,  //0xFFFFFFFE
};

This data is actually being stored as a StateSet* (pointer). The goal is that if the pointer is not used, its value will be null which is equivalent to the NotUsed value (no generic StateSet applies either). If it is generic, the value will either be 0xFFFFFFFF or 0xFFFFFFFE. For any other condition, it is interpreted as a pointer to an instance of StateSet.

The only time I can see this being an issue is if a state set was actually stored at either of these addresses which I see as theoretically impossible since sizeof(StateSet) > 2 and this would cause a crash anyway. Is this assumption correct? Or will this cause a problem?

[helios]

If this concerns you, you might also want to consider that (unsigned)-1 may not be equal to 2^n - 1.

These kinds of solutions are what makes programming with the Windows API so much fun. Can't you spare the two bits required to store this information someplace other than the pointer?

[primem0ver]

LOL. Well there are several reasons for doing this. One is that it won't just require two bits unless I have other data to store in the "int" that I would end up using. It also makes several things about the program (and programming) more efficient. Also... I suppose I should mention that this is on a Qt application that isn't just meant for windows. If it ever sees the light of day it will also be available for Macs, Linux, and possibly Android(? tablets only if android can run a c++ program) eventually.

I didn't quite follow your equation. What does the n refer to? Is n supposed to be the number of bits involved? Are you trying to say the pointer size may not be 32 bits?

[TwilightSpectre]

Well, a 64 bit system has 64 bit pointers, while that's not typically true of 32 bit systems.

[helios]

One is that it won't just require two bits unless I have other data to store in the "int" that I would end up using. It also makes several things about the program (and programming) more efficient.

This just sounds like premature optimization. A program would have to be extremely lean before it would be justifiable to use pointers to store enum values.

Also... I suppose I should mention that this is on a Qt application that isn't just meant for windows.

So?

I didn't quite follow your equation. What does the n refer to? Is n supposed to be the number of bits involved? Are you trying to say the pointer size may not be 32 bits?

I'm saying that nothing in the language guarantees two's complement arithmetic.
https://en.wikipedia.org/wiki/Signed_number_representations

[MiiNiPaa]

I'm saying that nothing in the language guarantees two's complement arithmetic.

Actuallt modulo 2 arithmetic is guaranteed for unsigned number so (unsigned)-1 is guaranteed to be 2ⁿ-1.
Though nothing guarantees that your enum will be unsigned. Or that pointer is unsigned. If you want that, you will need to use C++11 feature allowing to explicitely state underlying enum type.

The only time I can see this being an issue is if a state set was actually stored at either of these addresses which I see as theoretically impossible since sizeof(StateSet) > 2 and this would cause a crash anyway.

Depends on aligment requirements, struct content and usage of packed structures.