[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) unsigned int

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]