mcdaniel@adi.com (Tim McDaniel) (11/07/90)
gary@hpavla.AVO.HP.COM (Gary Jackoway) writes: > I don't think a compiler can make enums smaller than int and be ANSI > compliant, since the standard says that enums are ints. You're mixing 'enumeration constants' and 'enumerated types'. See Section 3.5.2.2 of the ANSI Standard. Enumeration constants (the identifiers between the { and the }) are of type 'int'. Then again, so are character constants, like '*'. "Each enumerated type shall be compatable with an integer type; the choice of type is implementation- defined." So the enum value itself might be a 'char', say, if the range of enumeration constants defined permits it. > It is for this reason that I almost never use enums. Their size > varies from machine to machine and there is nothing you can do about > it. It is for this reason that I almost never use character constants like 'a'. They're ints, so their size varies from machine to machine and there is nothing you can do about it. What C type DOESN'T vary in size from machine to machine? (Answer: none. The Standard only sets minima, and in practice there is variation. I suspect that there are or will be compilers with 16 bit or 32 bit 'char'.) Why in creation you CARE how much space they take? I can see only two reasons: (1) binary files, (2) memory space. Binary files are inherently unportable. Often, worrying about memory space is worshipping the Little Tin God of Efficiency. If you have a large array AND have severely limited memory, you may need to worry. Otherwise, you may save a few bytes, but you may pay for it in slower access time. Only optimize if you absolutely need the space or the time, and then only attack the areas with the biggest payoffs until you fit into your budget. > Then, some day if the language supports [arrays of bits], you will > be able to upgrade painlessly. Can't happen. "sizeof (char) == 1" is now fixed in the language, as is the fact that it yields an integral type. -- Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA Work phone: +1 313 973 1300 Home phone: +1 313 677 4386 Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
karl@ima.isc.com (Karl Heuer) (11/07/90)
In article <MCDANIEL.90Nov6114504@dolphin.adi.com> mcdaniel@adi.com (Tim McDaniel) writes: >[So, the array-of-enum might use up an int per slot. Who cares?] In particular, in the case of emulating a bit array, the distinction between 8-bit chars and 32-bit ints is less than that between chars and bits in the first place. If a 32-bit int is too wasteful, then so is an 8-bit char. >> Then, some day if the language supports [arrays of bits], you will >> be able to upgrade painlessly. > >Can't happen. "sizeof (char) == 1" is now fixed in the language, as >is the fact that it yields an integral type. What this really implies is that, if bit arrays are ever supported, they won't fit cleanly into the existing language and hence will probably not support all the same features as "normal" arrays. Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
kdb@chinet.chi.il.us (Karl Botts) (11/08/90)
>>Can't happen. "sizeof (char) == 1" is now fixed in the language, as >>is the fact that it yields an integral type. > >What this really implies is that, if bit arrays are ever supported, they won't >fit cleanly into the existing language and hence will probably not support all >the same features as "normal" arrays. I don't see how this follows. Given the new fundamental type "bit" (a keyword) then it does follow that: main() { bit bits[1]; printf("%d\n", sizeof(bits)); } must print (at least) "1". This is OK; sizeof produces the amount of storage needed to hold an object, not the actual size of the object. I would expect sizeof applied to an array of 8 bits to also return 1, tho of course this would be implementation dependent. Accessing elements of such an array would no doubt generate a little more code, probably involving the use of a mask, than accessing an element of an array of char; also, the address of an element of a bit array would likely be wider than addresses of other objects. But none of this is against the rules.
mcdaniel@adi.com (Tim McDaniel) (11/10/90)
Karl Heuer wrote: > What this really implies is that, if bit arrays are ever supported, > they won't fit cleanly into the existing language and hence will > probably not support all the same features as "normal" arrays. kdb@chinet.chi.il.us (Karl Botts) suggests that sizeof a hypothetical bit type in C could include padding to the nearest byte. > This is OK; sizeof produces the amount of storage needed to hold an > object, not the actual size of the object. I would expect sizeof > applied to an array of 8 bits to also return 1, tho of course this > would be implementation dependent. While the bit 8-) about padding is true, there are other rules and assumptions that would break. Which of the following do you want to break? Consider the costs of not breaking on byte-addressed architectures. * sizeof array / sizeof array[0] is the number of elements in an array. (ANS C standard section 3.3.3.2, "Examples" subsection.) * "void *" and "char *" have the same representation. (3.1.2.3, "Types".) * a "void *" can store a pointer to any incomplete or object type. (3.2.2.3, "Pointers".) * One of the operands to "[]" shall have type "pointer to object TYPE", and the result has type "TYPE". "E1[E2]" is defined to be identical to "(*(E1+(E2)))". (3.3.2.1, "Array Subscripting".) (Consider the standard "for (i = 0; i < NUM; i++)" to "for (p = &a[0]; p < &a[NUM]; p++)" transformation.) -- Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA Work phone: +1 313 973 1300 Home phone: +1 313 677 4386 Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (11/12/90)
>>>>> On 6 Nov 90 20:09:27 GMT, karl@ima.isc.com (Karl Heuer) said: >> Then, some day if the language supports [arrays of bits], you will >> be able to upgrade painlessly. > >Can't happen. "sizeof (char) == 1" is now fixed in the language, as >is the fact that it yields an integral type. Karl> What this really implies is that, if bit arrays are ever supported, Karl> they won't fit cleanly into the existing language and hence will Karl> probably not support all the same features as "normal" arrays. How about if sizeof() returns the smallest number of bytes that are required to contain a bit array of a given size? This would require no changes to malloc(), etc., to incorporate bit arrays. Most current architectures require alignment to something larger than a char, anyway. Of course, other things would be required to robustly implement bit arrays, (bit pointers, bitsizeof(), etc.) but I don't see that ANSI C has done anything to prevent this. In fact, by avoiding the areas of the language that are now _explicitly_ undefined, one is much less likely to be bit by bit pointers. (Sorry, I couldn't resist. :-) Just my $0.02, -- Chuck Phillips MS440 NCR Microelectronics chuck.phillips%ftcollins.ncr.com 2001 Danfield Ct. Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp