From 7627680148955741349 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7538bd92d6a9557a X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1995-01-20 21:34:59 PST Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!koriel!male.EBay.Sun.COM!engnews2.Eng.Sun.COM!clamage From: clamage@Eng.Sun.COM (Steve Clamage) Newsgroups: comp.std.c++ Subject: Re: short enum, bool Date: 21 Jan 1995 05:34:59 GMT Organization: Sun Microsystems Inc., Mountain View, CA Lines: 54 Message-ID: <3fq6e3$erb@engnews2.Eng.Sun.COM> References: <790640242snz@thone.demon.co.uk> NNTP-Posting-Host: taumet.eng.sun.com X-Newsreader: NN version 6.5.0 #21 (NOV) andys@thone.demon.co.uk (Andy Sawyer) writes: >In article > baynes@ukpsshp1.serigate.philips.nl "Stephen Baynes" writes: >[snip stuff about 'short enums'] >> Some C and C++ compilers do offer this as an extension. However for space >> saving it is unecessary - just buy yourself a good compiler - this will >> chose the size of an enum according to the range of the enumeration values >> you specified for it. > I've wonder about this for a while, as it leads me to think that >sizeof( enum ) may be meaningless. Since the compiler is, as you say, free >to choose the size of an enum, what happens in the following case: > enum little { l_lo = 0, l_hi = 1 }; // Will fit in a single bit > enum big { b_lo = 0, b_hi = 256 }; // Needs at least 9 bits > cout << ( ( sizeof( little ) == sizeof( big )) ? "l==b" : "l!=b" ) << endl; > cout << ( ( sizeof( little ) == sizeof( enum )) ? "l==e" : "l!=e" ) << endl; > cout << ( ( sizeof( big ) == sizeof( enum )) ? "b==e" : "b!=e" ) << endl; The sizeof any enumeration type or object is well-defined in a program, although implementation-defined. The language rules do not address things like compiler command-line options to change the sizes of types. You are on your own if you use such options inconsistently. (It violates the One-Definition Rule, since type 'big', for example, would have different definitions in different translation units in the same program.) There are no language requirements governing the relative sizes of your two enums. They could be the same size, or 'little' could be larger than 'big'. > Even more curious would be the case of > enum big_x { big_x_lo = 1, big_x_hi = 256 }; > Would it be legal for a compiler to implement this as an 8 bit value, >applying a +/- 1 adjustment on conversions to/from the type? What about >a single bit? (Probably not the latter - but the former?) No. Type big_x is required to be able to represent all values from 0 through 511 under the new language rules. It must therefore occupy at least 9 bits. Type 'little' can be represented in one bit, but every object must have a size of at least 1. Two different objects of type 'little' must have different addresses (except for bitfields) so as a practical matter, the object will take up at least as much space as a char. (By definition, sizeof(char)==1.) -- Steve Clamage, stephen.clamage@eng.sun.com