From: David Abrahams (dave_at_[hidden])
Date: 2005-03-12 22:52:45
JOAQUIN LOPEZ MU?Z <joaquin_at_[hidden]> writes:
> ----- Mensaje original -----
> De: David Abrahams <dave_at_[hidden]>
> Fecha: Domingo, Marzo 13, 2005 0:52 am
> Asunto: [boost] Re: [review] hash functions
>> Alberto Barbati <abarbati_at_[hidden]> writes:
>> > Ah! And there's one more case in which we are helpless, although
>> > curious to see an implementation that exploits such latitude:
>> > wording used in the standard does not guarantee that the mapping
>> > pointers to integers always produce the same value over time. In
>> > words:
>> > char* p = new char;
>> > size_t i1 = reinterpret_cast<size_t>(p);
>> > size_t i2 = reinterpret_cast<size_t>(p);
>> > assert(i1 == i2); // ???
>> > char* q1 = reinterpret_cast<char*>(i1);
>> > char* q2 = reinterpret_cast<char*>(i2);
>> > assert(p == q1 && q1 == q2);
>> > The standard guarantees that the second assert passes, but says
>> > about the first assert.
>> There are other cases too. reinterpret_cast could map all
>> pointers to
>> the same integer.
> If you allow me to be a little pedantic, this is not the
> case. reinterpret_cast<> guarantees back conversion, so it can't
> possibly map every pointer into the same integer.
4 A pointer can be explicitly converted to any integral type large
enough to hold it. The mapping function is implementation-defined
[Note: it is intended to be unsurprising to those who know the
addressing structure of the underlying machine. ]
5 A value of integral type or enumeration type can be explicitly
converted to a pointer. 64) A pointer converted to an integer of
sufficient size (if any such exists on the implementation) and back
to the same pointer type will have its original value; mappings
between pointers and integers are otherwise implementation-defined.
There's no guarantee that the integer type will have sufficient size.
> As for the rest of your argument, I agree 100%.
Now you agree with all of it ;-)
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk