throopw@rtp47.UUCP (Wayne Throop) (09/27/85)
In the "short vs int vs long" discussion, a topic comes up that I'd like to comment on. To review: > >> But I can't quite fiqure out what you mean here. Does it mean that > >> is if 'short' 'int' and 'long' are the same size then I should > >> choose something other than 'int'? > > > You did figure out what I meant - that is exactly what I mean! If > > you want to have a variable that can hold values outside the range > > -32767 to 32767, use "long", regardless of whether something else > > just might happen to work. > > If one is very concerned about portability to other-wordlength machines, why > not use typdefs like: > > typedef int bit16; > typedef long bit32; > > Then make all your declarations as bit16, bit32, etc. > > Robert Clark Good idea. But beware of using these when what you mean is not what the typedef implies. In particular, many implementers typedef physical layouts as above when what they really want to abstract is *not* physical layout, but something else again. For example, on a Unix(tm) system, should one declare a variable to hold a process id as a bit16, and is that more "abstract" than defining it "short"? I maintain that "proper" use of C would typedef (or #define) an abstract handle for "pid_type", and then declare variables that hold pids to be the abstract type. Thus, "bit16", "bit32", and the like are good ideas, but beware. These names should *only* be used where physical layout is the major concern (that is, almost nowhere). -- Wayne Throop at Data General, RTP, NC <the-known-world>!mcnc!rti-sel!rtp47!throopw
mwm@UCBOPAL.CC (Mike (I'll be mellow when I'm dead) Meyer) (10/04/85)
In article <199@rtp47.UUCP> Wayne Throop (throopw@rtp47) writes: >Thus, "bit16", "bit32", and the like are good ideas, but beware. These >names should *only* be used where physical layout is the major concern >(that is, almost nowhere). There is one other place. If you know that some variable will always fit in some size (i.e., you could make it a subrange type in Pascal), then declaring it to be of type int<n> (or uint<n>, if it's unsigned) allows the compiler to choose the smallest type it will fit in. On the other hand, if you're worried about speed, you should declare it as an int if it's small. I even have a file of typedefs that works for VAX-like machines that declares int<n> and uint<n> correctly. <mike
throopw@rtp47.UUCP (Wayne Throop) (10/06/85)
> In article <199@rtp47.UUCP> Wayne Throop (throopw@rtp47) writes: > >Thus, "bit16", "bit32", and the like are good ideas, but beware. These > >names should *only* be used where physical layout is the major concern > >(that is, almost nowhere). > > There is one other place. If you know that some variable will always fit in > some size (i.e., you could make it a subrange type in Pascal), then > declaring it to be of type int<n> (or uint<n>, if it's unsigned) allows the > compiler to choose the smallest type it will fit in. I disagree. That is, I don't think that "int<n>" should be used as the abstract handle in declaring "enumeration-like integers" that take on values in a specific range. For two reasons: 1) It doesn't capture all the range information you "really" know about the values instances of the type can take on. It only captures range information to the nearest power of two. 2) It still doesn't distinguish two different usages of "integers in the range of -2^(n-1) to +2^(n-1)". In some OS, process id's and file descriptors might have the same integer range, but I still wouldn't like to declare them the same type. Therefore, this usage is "not abstract enough" for my taste. > On the other hand, if you're worried about speed, you should declare it as > an int if it's small. Nope. You should declare it to be a typedefed type with a name like (oh, say) "speedy_subrange_type", which suggests correctly that it takes on the same values as does "subrange_type", and speed of access is important. Of course, the definition of this type is likely to be "int", but this is quite different from declaring things "int" directly. Again, I think that "primitive types" should almost never be used to declare abstract entities, like pids, or file descriptors, or file positions, or "nice" values, or (blah blah blah). The "n bit long" types are also not suitable for these purposes, for about the same reasons that primitive types are not suitable. So there. :-) > From: mwm@UCBOPAL.CC (Mike (I'll be mellow when I'm dead) Meyer) -- Wayne Throop at Data General, RTP, NC <the-known-world>!mcnc!rti-sel!rtp47!throopw