Stroustrup 4.8 Enumerations

after reading that sections, i know:

- an "enum" is user-defined type
- there is no implicit conversion from an "int" to an "enum" BUT an
"int" can be converted to an "enum" *explicitly*.

the thing i did not understand is the "range" of an "enum":

enum e1 { dark, light } // range 0:1

that is fine as dark == 0 and light == 1 (both are of type e1, not
"int")

enum e2 {a = 3, b = 9} // range 0:15

how come ? i think the range here is 0 - 9.

enum { min = -10, max = 1000000 } // range -1048576:1048575

hoe come here ?

Stroustrup also explained it:

"the range of an enumeration holds all the enumeration's enumerator
values rounded upto the nearest largest binary power minus 1. the
range goes down to zero if the smallest enumerator is non-negative and
nearest lesser negative binary power if the smallest enumeration is
negative. this defines the smallest bit-field capable of holding the
enumerator values."

so by this rule range of "e2" must be: 0 to 256 (which is 2^8,
because 9 -1 == 8)

i do not understand anything here :-(

even the last line is simply alien to me: "this defines the smallest
bit-field capable of holding the enumerator values"

what exactly is "bit-field" ?

re: Stroustrup 4.8 Enumerations

On Mar 26, 12:02 pm, "arnuld" <geek.arn...@gmail.comwrote:OK, i red this thread:

http://groups.google.com/group/comp....5d16e2bfded281

and understood the "range" phenomenon.

but still, i did not understand this

"this defines the smallest bit-field capable of holding the enumerator
values"

what exactly is "bit-field" ?

?

re: Stroustrup 4.8 Enumerations

arnuld a écrit :You have the answer:Binary powers: 2,4,8,16,32 ....

nearest largest binary of 9 is 16.
Minus one: 15

Thus range is 0-15
In this case, there is a negative value.
With only positives, range would have been 0-1048575.
Since there is a neg value and since C++ has 1 complement signed
representation, the equivalent integer (2^21) has the range:
-1048576:1048575

8 is 2^3 so Three bits is enough for range 0-7 (in unsigned case).
4 bits represent the range 0-15 (in unsigned case).
a bit field is an integer represented on a specified number of bits.

int i:4; //is a 4 bits signed integer (range -8 - 7)
unsigned integer u:6; //is a 4 bit unsigned integer (range 0 - 15)


If you have the standard, it should be specified somewhere;


Michael

re: Stroustrup 4.8 Enumerations

Michael DOUBEZ a écrit :[bug] :)
unsigned integer u:4; //is a 4 bit unsigned integer (range 0 - 15)


Michael

re: Stroustrup 4.8 Enumerations

On Mar 26, 12:29 pm, Michael DOUBEZ <michael.dou...@free.frwrote:nearest largest binary power: 2, 4, 6, 8 is 6.

minus 1 == 6 - 1 == 5

so the range is 0-5, how it is 0-15 ?

re: Stroustrup 4.8 Enumerations

* arnuld:4 bits yield 2*2*2*2 = 16 bitpatterns, or values.

Unsigned range 0 through 15, inclusive, which is 16 values.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

re: Stroustrup 4.8 Enumerations

On Mar 26, 2:28 pm, "Alf P. Steinbach" <a...@start.nowrote:
thanks Alf.

now for "signed i = 4" we have 1 bit for reserved for "sign",

so 3 bits = 2*2*2 = 8

how ill i decide the range of values in this case ?

re: Stroustrup 4.8 Enumerations

* arnuld:Well stop right there. There's a /huge/ difference between

signed x:4;

in a struct somewhere, saying that x is four bits, and

signed x=4;

saying that x is an int (a.k.a. signed int a.k.a. signed) initialized
with the value 4.

Your original problem had to do with understand the range of an enum
type, i.e. what values you can store in a variable of that type.

Here's a simple algorithm:

1. If unsigned int or signed int can hold any of the values specified
in the enum declaration, then the /underlying type/ of the enum is
int, unsigned int or something smaller (such as e.g. short).

2. Otherwise, it's something larger.

Essentially that's all the standard says and all that you can rely on,
namely that the underlying type of an enum will not be more bits than
'int' unless necessary to represent all defined values of the enum.

It's a kind of memory efficiency guarantee, that an enum type will not
be arbitrarily large unless a named value exceeds the range of int or
unsigned int.

Suprisingly there's no such guarantee for 'bool'. In theory, a 'bool'
could be 2 gigabytes -- or more! Needless to say, no compiler
implements it that way (it's typically one byte), but that's the formal.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

re: Stroustrup 4.8 Enumerations

.. On Mar 26, 3:44 pm, "Alf P. Steinbach" <a...@start.nowrote:interesting, i did not know that. i thought, the "x:4" is an eye-
pleasing thing.

yep, you got me ;-)

you said: it is an algorithm.

how can it be? there is not MATH in it.


ok, an enum will always be: int or unsigned int (or short)

EXCEPT if i intentionally put large values into an enum. i got it.

BTW, i know that /plain int/ is always signed.
=:-0
what is the context of using: formal

re: Stroustrup 4.8 Enumerations

arnuld <geek.arnuld@gmail.comwrote:An algorithm is basically a series of steps used to solve a problem. It
doesn't necessarily have to be a math problem.
He is saying that the Standard makes no formal guarantees on the size of
bool, but as a QoI (quality of implementation) issue, nobody would use a
compiler that used 2 gigabyte bools, even though there is nothing in the
Standard preventing someone from doing so.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply