Re: casting (void *) to (class *)
* James Kanze:
On Apr 15, 1:58 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Apr 15, 4:04 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Jonathan Lee:
But better, don't use void* pointers (except for the
special case of identifying objects in e.g. a hash table,
in which case you should make sure to have pointers to
complete objects, e.g. obtained by dynamic_cast to void*).
I'm not sure I understand this one. Do you mean just using
the pointer as the key?
Yes.
(And how do you get a hash value for a pointer, portably?)
Wait a sec, checking Boost...
KO.
// Implementation by Alberto Barbati and Dave Harris.
#if !BOOST_WORKAROUND(__DMC__, <= 0x848)
template <class T> std::size_t hash_value(T* const& v)
#else
template <class T> std::size_t hash_value(T* v)
#endif
{
std::size_t x = static_cast<std::size_t>(
reinterpret_cast<std::ptrdiff_t>(v));
return x + (x >> 3);
}
Then reduction to the internally required range of the
particular hash table is the responsibility of that hash
table.
Of course. But the above isn't guaranteed to work, and I've
worked on systems where it wouldn't work. (By not working, I
mean that two pointers which compare equal will result in
different hash values.)
I think that problem is academic.
It is the problem of a platform not supporting Boost. :)
If one could find a C++ compiler for 16-bit Windows or MS-DOS and compile in
anything but "large model" there would be a problem. Actually I still have the
CD for such a compiler, Visual C++ 1.5 :) But it's not standard C++.
We can *imagine* some embedded system using e.g. an 80286 or something, and
segemented addressing.
But it's a myth that standard C++ is applicable to such systems.
I also know of one system where it is
almost useless. Where for any dynamically allocated complete
object, x would always have the same value.
The standard guarantees roundtrip conversion for integer of "sufficient size".
So when the integer is of "sufficient size" conversion to integer can't yield
the same value for different pointer values.
The above supposes
a one to one mapping between pointers and the integral types
involved, which is far from universal.
It can only be far from universal if there are a number of systems with C++
compilers where those integer types, ptrdiff_t and size_t, are not of the
"sufficient size" required by the standard for roundtrip conversion.
I also don't see why the double cast, rather than casting
directly to size_t,
Me neither.
If anything, perhaps it is designed to encourage discussion about why the heck
they're doing that. :)
But there is a difference, namely that for a sign-and-value representation of
signed integers, it maps binary 00...0 and 10...0 to the same size_t value, 0.
and the expression in the return statement is a hack.
Sort of. A maximum alignment of 8 is pretty universal. And it's only a "value
adding service" so to speak, for the hashing can't guarantee lack of collisions
in the final reduction to hast table size; it can only make it less likely.
If they're willing to restrict the function to
architectures with a one to one mapping, then they might as well
restrict it to architectures without any padding bits in
integral types as well, and just do a classical hash treating
the pointer as an array of bytes.
Well, they're relying on the guaranteed roundtrip conversion for "sufficient
size" integers, which means guaranteed unique values.
As I see it. :-)
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!