Abstraction

[Wayne Throop]

> In article <199 at rtp47.UUCP> Wayne Throop (throopw at 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 at 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