Re: [boost] Re: [review] hash functions
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 0:52 am Asunto: [boost] Re: [review] hash functions
Alberto Barbati <abarbati@iaanus.com> writes:
Ah! And there's one more case in which we are helpless, although I'm curious to see an implementation that exploits such latitude: the wording used in the standard does not guarantee that the mapping from pointers to integers always produce the same value over time. In other 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 nothing 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. As for the rest of your argument, I agree 100%. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z <joaquin@tid.es> writes:
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 0:52 am Asunto: [boost] Re: [review] hash functions
Alberto Barbati <abarbati@iaanus.com> writes:
Ah! And there's one more case in which we are helpless, although I'm curious to see an implementation that exploits such latitude: the wording used in the standard does not guarantee that the mapping from pointers to integers always produce the same value over time. In other 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 nothing 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 ;-) (I hope) -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ubr9ow6b6.fsf@boost-consulting.com... | JOAQUIN LOPEZ MU?Z <joaquin@tid.es> writes: | >> 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. | | 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. BOOST_STATIC_ASSERT( sizeof(void*) >= sizeof(std::size_t)) ? -Thorsten
Thorsten Ottosen wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ubr9ow6b6.fsf@boost-consulting.com...
There's no guarantee that the integer type will have sufficient size.
BOOST_STATIC_ASSERT( sizeof(void*) >= sizeof(std::size_t))
?
The reverse, probably. Technically, it's still not enough; sizeof gives you the size of the object in chars, not the number of value bits. This aside, the assert doesn't tell you whether reinterpret_cast produces a reasonable hash value; this is an inherently non-portable characteristic of the particular platform.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:00aa01c52800$a3257820$6501a8c0@pdimov2... | Thorsten Ottosen wrote: | > "David Abrahams" <dave@boost-consulting.com> wrote in message | > news:ubr9ow6b6.fsf@boost-consulting.com... | >> | >> There's no guarantee that the integer type will have sufficient size. | > | > BOOST_STATIC_ASSERT( sizeof(void*) >= sizeof(std::size_t)) | > | > ? | | The reverse, probably. yeah, right. | Technically, it's still not enough; sizeof gives you | the size of the object in chars, not the number of value bits. just so I get this, you're saying that even though sizeof( int ) == 4, the implementation could choose to use only the first two bytes for the representation? -Thorsten
Thorsten Ottosen wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:00aa01c52800$a3257820$6501a8c0@pdimov2...
Technically, it's still not enough; sizeof gives you the size of the object in chars, not the number of value bits.
just so I get this, you're saying that even though sizeof( int ) == 4, the implementation could choose to use only the first two bytes for the representation?
Or the middle 24 bits, yes. Integers are allowed to have padding. Same with pointers.
participants (4)
-
David Abrahams -
JOAQUIN LOPEZ MU?Z -
Peter Dimov -
Thorsten Ottosen