john@viper.Lynx.MN.Org (John Stanley) (03/01/88)
>> Another thing that should go is the assumption that the unit of storage is >> the byte. The base unit of storage is the bit, and sizeof should return the >> number of bits in the object. This enables to treat objects smaller than a >> byte as first class objects. While I'm totaly against changing the existing functionality of the sizeof() operator, what I would be totaly in favor of would be the addition-to-ansi-C of a new operator that would have a similar functionality, but which would return the number of -bits- in something. The name bitsize() would be my suggested name for this operator. This would provide one MAJOR advantage. It would allow writing code or header files that would be 100% portable without having to know about each and every compiler/OS/machine's identifer defines. If you needed a 12 bit integer type, your headers could have #if statements that would provide the next integer type equal or larger that 12 bits. No more #ifdef'ing special integer types individualy for each system when you're trying to make efficient code run on multiple machines. An additional minor advantage would be the capability of writing the kinds of functions we normaly use sizeof for to work with bitfield variables.. This is a relatively minor addition to any existing compiler (multiply sizeof by 8 for most machines... and return the bitsize that's probably already a field in the evaluation structure for a bitfield variable...) and would make some major advancements possible in source code portability... Doug Gwyn, I'd appreceate hearing your reaction on this suggestion. If it's never come up as a suggestion, feel free to play with it. If it's been considered and rejected, I'd like to hear the reasoning behind the rejection. --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/03/88)
In article <664@viper.Lynx.MN.Org> john@viper.UUCP (John Stanley) writes: >... addition-to-ansi-C of a new operator that would have a similar >functionality, but which would return the number of -bits- in >something. The name bitsize() would be my suggested name for this >operator. It's already basically there: #include <limits.h> /* (we may have to rename this header) */ #define bitsize(obj) (CHAR_BIT*sizeof(obj)) The only thing this doesn't work on is bit-fields, functions, or incomplete types.
rcvie@tuvie (ELIN Forsch.z.) (03/03/88)
In article <664@viper.Lynx.MN.Org> john@viper.UUCP (John Stanley) writes: > > While I'm totaly against changing the existing functionality of the >sizeof() operator, what I would be totaly in favor of would be the >addition-to-ansi-C of a new operator that would have a similar >functionality, but which would return the number of -bits- in >something. The name bitsize() would be my suggested name for this >operator. > > This would provide one MAJOR advantage. It would allow writing code >or header files that would be 100% portable without having to know >about each and every compiler/OS/machine's identifer defines. This seems superflous to me. ANSI guarantees sizeof(char) to be 1 and provides a macro in <limits.h> named CHAR_BIT that expands to the number of bits used for one char. So the number of bits for a specific data type is simply sizeof(SpecificDataType)*CHAR_BIT. >If you >needed a 12 bit integer type, your headers could have #if statements >that would provide the next integer type equal or larger that 12 bits. >No more #ifdef'ing special integer types individualy for each system >when you're trying to make efficient code run on multiple machines. You cannot use the sizeof operator in #if expressions as the preporcessor does not know anything about types. Symetrically it would not know anything about bit sizes. I cannot see, how you would be able to use bitsize during preprocessing. > > An additional minor advantage would be the capability of writing >the kinds of functions we normaly use sizeof for to work with bitfield >variables.. > > This is a relatively minor addition to any existing compiler >(multiply sizeof by 8 for most machines... and return the bitsize >that's probably already a field in the evaluation structure for a >bitfield variable...) and would make some major advancements possible >in source code portability... Try the following: #define bitsize(whatever) sizeof(whatever)*CHAR_BIT This has only one disadvantage: you are not able to use a syntax without parentheses as you can with sizeof (e.g. sizeof "a text"). My opinion is, not to create operators too freely. In C operators have been chosen in a way, that (nearly) every operator yields in one processor operation (+, -, ...) or a constant (sizeof). This helps when one has to estimate about the runtime of a program. For this reason I dislike operators that yield (always) in functions like power, sin, etc. bitsize does not fall into this category, but into category of not needed. Anyway such a new operator could start an inflation that "optimizes away" some nice philosophies of C. Dietmar Weickert, ALCATEL-ELIN Research Center, Vienna, Austria. P.S.: I apologize if my English is of unreadable style!