Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bbn!uwmcsd1!dogie!uwvax!umn-d-ub!umn-cs!meccts!viper!john
From: john@viper.Lynx.MN.Org (John Stanley)
Newsgroups: comp.lang.c
Subject: bitsize() operator (was: The D Programming Language)
Message-ID: <664@viper.Lynx.MN.Org>
Date: 29 Feb 88 20:28:49 GMT
References: <2718@mmintl.UUCP> <1988Feb25.202237.8688@utzoo.uucp>
Reply-To: john@viper.UUCP (John Stanley)
Organization: DynaSoft Systems
Lines: 39
Summary: suggestion of bitsize() operator for ansi-C


 >> 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