Re: Hash Type Size

["Randy Brukardt" <randy@rrsoftware.com>]

<sbelmont700@gmail.com> 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.