Gregory Stark wrote:
> > The width is 4 both for the macro and the enum case. Both
> >
> > #define TYPTYPE_BASE 'b'
> >
> > and
> >
> > enum ... {
> > TYPTYPE_BASE = 'b',
> >
> > effectively generate int constants named TYPTYPE_BASE with decimal
> > value 98. So there are no storage advantages either way.
>
> That's not accurate at all.
How so?
> The macro case gives you a constant you
> can only use to initialize integer variables and members that are
> explicitly declared with some integral type. If we consistently
> declare them "char" then they'll be predictably 1 byte long.
But character constants are actually ints, so when you do what you
describe then the compiler has to generate code to copy a four-byte
integer into a single byte. (Of course that can be optimized away,
probably.)
> The enum case does two things. It defines a syntactic meaning for the
> label, *and* it defines a thing "enum typtype" which can be used to
> define variables and members. If the latter is used then Tom is
> saying the standard doesn't specify what width the variable or member
> will be.
The standard says that enums are the same as ints. So when you assign
an enum label to a char variable, then compiler has to generate code to
copy a four-byte integer into a single byte. (Of course that can be
optimized away, probably.)
The fact that you can also declare variables of the enum type is not
under consideration here.
QED
--
Peter Eisentraut
http://developer.postgresql.org/~petere/