[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optimizing memory footprint of bidi code
From: |
Tom Tromey |
Subject: |
Re: Optimizing memory footprint of bidi code |
Date: |
Mon, 07 Jun 2010 09:14:36 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
>>>>> "Eli" == Eli Zaretskii <address@hidden> writes:
Eli> I see a bidi_dir_t enumeration that has only 3 possible values. Can
Eli> we trust modern compilers to use the smallest integer type for
Eli> enumerations? If so, this part is already taken care of. If not, how
Eli> to make this type smaller without losing the benefits of an enumerated
Eli> type (I don't want to manipulate magic values or macros)?
In C an enum is always an int. In a struct the compiler will not
automatically shrink this to a bitfield.
However, you can declare it as a bitfield. GCC will check to make sure
that all the enumeration values fit in the bitfield, so you will get an
error if you add a constant to the enum causing it to no longer fit.
Bitfield enums are not portable. So, gcc and gdb do this:
#if defined(__GNUC__) && (__GNUC__ >= 2)
#define ENUM_BITFIELD(TYPE) enum TYPE
#else
#define ENUM_BITFIELD(TYPE) unsigned int
#endif
Then in the definition:
struct main_type
{
...
ENUM_BITFIELD(type_code) code : 8;
...
};
I think this approach results in a good tradeoff of type safety, size,
and portability, as long as a significant fraction of developers are
using GCC.
Eli> Maybe manipulating bitfields is no longer an issue with current
Eli> architectures and compiler technology.
It increases code size, which can matter. The only way to know for sure
is to try it and profile.
I can't answer the rest of your questions.
Tom