From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/12 Message-ID: #1/1 X-Deja-AN: 297604219 References: <66po35$1a1$1@gte2.gte.net> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 881948029 28642 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-12-12T00:00:00+00:00 List-Id: Matthew Heaney says <>> I strongly disagree. In fact this particular example, of Booleans that differ by multiple bits, is one of the strong justifications in past discussions of keeping holey enumeration types in the language. Note that in this case it is in practice quite unusual to have loops through Boolean, or arrays with a Boolean subscript, so typically there is ZERO overhead in using this representation, and you get the one-bit-clobbered protection. If you convert these boolean values to application format, you are introducing an unnecessary lack of safety at the hardware level, namely a sensitivity to undectable one-bit errors that does not exist with the non-standard representation. This is an entirely appropriate way to use this feature, and the language was deliberately designed to facilitate this usage. I see nothing 'pretty horrible' about this approach, and it is a commonly used one. Brian Wichman has pointed this particular usage out on a number of occasions and explained why it is important (indeed as I remember there are contexts in which coding standards *require* this kind of approach, and such standards make good sense to me!) Robert Dewar