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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Hash Type Size Date: Mon, 19 Aug 2013 17:12:13 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1679ec49-424b-43bd-8f35-a5f69e658112@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1376950334 22141 69.95.181.76 (19 Aug 2013 22:12:14 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 19 Aug 2013 22:12:14 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:16908 Date: 2013-08-19T17:12:13-05:00 List-Id: wrote in message news:1679ec49-424b-43bd-8f35-a5f69e658112@googlegroups.com... >What is the size of Ada.Containers.Hash_Type intended to be? It's implementation-defined, of course. The formal language makes no requirement on the size. > The LRM advises that "Hash_Type'Modulus should be at least 2**32", but > this > makes hashing a value on a 64-bit machine particularly unpleasant, since > my > implementation (MinGW-64) still defines it as 32-bit. Is the intent that > Hash_Type > should be the native size of the machine (and the implementation is > wrong/advice is > vague), or that it actually should be 32-bit if possible? Like Integer, the advice is that it should be at least a particular size, and nothing more is said. I'm pretty sure there is no intent at all (so far as I recall, we never discussed anything about that). The reason for the 32-bit advice is to ensure that there are plenty of values available (16-bit wouldn't be enough). If you want truly portable code, you have to hash a stream element representation of your data anyway, so there doesn't seem to be much advantage to requiring more than that. So many Ada programmers make unwarranted assumptions about the sizes of things. Ada has no notion of "native size" and writing code that depends upon that is just not going to be portable. I've see many pieces of code that assume that Integer has 32-bits (not true in Janus/Ada), that Long_Integer has 64-bits (not true in Janus/Ada), that the size of System.Address is the same as an access type (not true in 16-bit versions of Janus/Ada, and probably some others as well). Almost everyone assumes that integers have a two's complement representation (that caused all kinds of problems for our U2200 compiler, which of course is a one's complement, 36-bit machine). Moral: unless the RM *requires* something, don't write code that depends upon it. Randy.