«

"" <> writes:
> On Nov 26, 8:24 pm, "copx" <c...@gazeta.pl> wrote:
>> C's enum type disappoints me a lot.
>>
>> You cannot define which type of integer variable is used. This contradicts
>> C's low level spirit. "I want a number variable. I do not care about size or
>> execution speed." feels like typical ultra high level scripting language
>> design. The compiler could not optimize an enum if it wanted to, because you
>> cannot even specify whether memory requirements or speed are your primary
>> concern. Enums were meant to replace these endless lists of defines you find
>> all over older C source:
>> #define FOO 0
>> #define BAR 1
>> ..
>> It is a technique commonly used to give index numbers meaningful names.
>> However, the variables which hold such numbers often do not need to be wider
>> than one byte and are used a lot. In one program I had many enum-type
>> variables as parts of my data structures and the amount of wasted RAM was
>> excessive when I used C enums, because the compiler (GCC) always used
>> (unsigned) ints, even if the entire range of valid values fitted into a
>> single byte.
>
> Isn't that GCC's fault to waste memory and not a language flaw?
>
> At least my understanding is that the actual enum type can be chosen
> freely by the implementation as long it can fit all values [1]. So GCC
> _could_ have used a byte (octet).

Yes, it could, but why should it? On many systems, operations on
words (e.g., int or unsigned int) are faster than operations on bytes.
In some cases, data space saved by using bytes might be more than
offset by the increase in code size.

--
Keith Thompson (The_Other_Keith) <kst->
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Nov 30, 7:16 pm, Keith Thompson <ks...@mib.org> wrote:
> "kar1...@gmail.com" <kar1...@gmail.com> writes:
> > On Nov 26, 8:24 pm, "copx" <c...@gazeta.pl> wrote:
> >> C's enum type disappoints me a lot.
>
> >> You cannot define which type of integer variable is used. This contradicts
> >> C's low level spirit. "I want a number variable. I do not care about size or
> >> execution speed." feels like typical ultra high level scripting language
> >> design. The compiler could not optimize an enum if it wanted to, because you
> >> cannot even specify whether memory requirements or speed are your primary
> >> concern. Enums were meant to replace these endless lists of defines you find
> >> all over older C source:
> >> #define FOO 0
> >> #define BAR 1
> >> ..
> >> It is a technique commonly used to give index numbers meaningful names.
> >> However, the variables which hold such numbers often do not need to be wider
> >> than one byte and are used a lot. In one program I had many enum-type
> >> variables as parts of my data structures and the amount of wasted RAM was
> >> excessive when I used C enums, because the compiler (GCC) always used
> >> (unsigned) ints, even if the entire range of valid values fitted into a
> >> single byte.
>
> > Isn't that GCC's fault to waste memory and not a language flaw?
>
> > At least my understanding is that the actual enum type can be chosen
> > freely by the implementation as long it can fit all values [1]. So GCC
> > _could_ have used a byte (octet).
>
> Yes, it could, but why should it? On many systems, operations on
> words (e.g., int or unsigned int) are faster than operations on bytes.
> In some cases, data space saved by using bytes might be more than
> offset by the increase in code size.

OTOH, CPUs run way faster than the memory latency (100/1000 times?).
So any denser representation of data may not only result in less DRAM
usage, it will reduce the amount of data that must come into the CPU.
This can translate to a faster overall performance (less total time).

These days memories are getting bigger and cheaper and hence saving
DRAM usage may not be a bigger concern. Reducing the amount of data
that is shuttled back/n/forth from CPU to the memory will contribute
to a reduction in total time. Thus optimizing for space and time need
not be mutually exclusive.

In any case, I think this issue is orthogonal to the OP's original
concern that the language mandates enum types to be int; which it does
not (starting C99).

Karthik


>
> --
> Keith Thompson (The_Other_Keith) <ks...@mib.org>
> Looking for software development work in the San Diego area.
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"

wrote:
> [...]
> In any case, I think this issue is orthogonal to the OP's original
> concern that the language mandates enum types to be int; which it does
> not (starting C99).

For clarity: The enumeration constants are all of type
`int', but the enum type itself is a distinct type of its
own, not an `int'. ANSI Classic 3.1.2.5p9 (before the ISO
re-numbering).

--
Eric Sosman
lid