Re: casting (void *) to (class *)
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 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 above supposes
a one to one mapping between pointers and the integral types
involved, which is far from universal.
I also don't see why the double cast, rather than casting
directly to size_t, and the expression in the return statement
is a hack. 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.
However, void* may be practically necessary in the context
of a C code callback.
Yes, and you can encounter a similar problem to the above.
Some context must have disappeared here.
Maybe. I think you mentionned something about having to be sure
that the void* was obtained from the complete object, and not by
e.g. a static_cast of a pointer to a base class. The problem
being that converting pointers to different base classes of an
object may result in different void*. The problem with
callbacks is basically the same: a void* obtained by converting
from the address of the complete object may not be the same as
one obtained by converting from a pointer to a base class.
About the only legal thing you can do with a void* is cast it
back to the original type (and only that type) before using it.
(You can, of course, copy it and compare it.)
And you can cast from POD* to FirstMember*.
Or the other way.
Yes. It's highly unlikely that POD or FirstMember have type
void. But I think you can go through a void* in those
conversions. (I'm not sure that the standard guarantees it, but
in practice, you surely can, given that the conversion without
passing through void* is legal, and converting to void* and back
to the original type must work.)
Thus, the following is undefined behavior:
Derived* p1 = new Derived ;
void* p2 = p1 ;
Base* p3 = static_cast< Base* >( p2 ) ;
p3 -> ...
The second line must be written:
void* p2 = static_cast< Base* >( p1 ) ;
for the rest to work.
(This often happens in callback contexts, e.g. pthread_create or
CreateThread, where the called function does something like:
void*
newThread( void* p )
{
static_cast< Base* >( p )->run() ;
}
Passing the address of this function and a pointer to a
derived type to pthread_create or CreateThread will cause
undefined behavior.)
Isn't it fun.
Especially because in practice, the erroneous code works in a
lot of cases. Until some change in an apparently unrelated part
(addition of a second base class to Derived, for example) causes
it to break.
For context, it's for a "thread" class with pthreads
backing it. I know that the void* was originally a pointer
to the class and it is merely being restored to the
correct type (it's just the _this_ pointer being mangled
by pthread_create).
There is a good chance that the original pointer was just
implicitly converted to void*, in which case the conversion
was equivalent to a static_cast, which is then what you
should do to get back the original.
But consider using Boost threads.
AFAIK they're based on pthreads, but offering a more type
safe C++ interface, and in addition, will be part of C++0x
so using them is preparing for the future...
Actually, this is one place where the standard did evolve
significantly from Boost: the thread and its identifier have
been separated,
Ouch.
Ouch in what sense? That you've got a lot of code using Boost,
and that converting it to the standard will be a lot of work?
The reasonning behind this is simple (sort of): a thread, per
se, has identity, and shouldn't be copiable (although the
standard version is movable). A thread identifier, however,
should be copiable, so it can be used in standard containers.
there is an explicit function for detach (although the
implicit detach in the constructor is still there, rather
than having it an error condition to destruct a joinable
thread), and of course, the standard type makes use of new
standard features, like rvalue references and move
semantics.
Do the C++0x threads require use of the rvalue stuff?
I don't think they require it. I imagine that there are some
cases where it might be useful, however. If nothing else, it
allows you to create a thread in a function and return it, so
that the calling code can do the join. Without movability
(which supposes rvalue references), you'd have to allocate it
dynamically, or give up identity, both of which have other
problems.
That is, have they re-designed the threads so that they break
existing code and can't be reasonably implemented in C++98?
Well, they can't break existing code, because no existing code
uses std::thread. And most of the library in the new standard
can't be implemented in C++98, because there are rvalue
references everywhere. (And of course, you can't implement
anything which uses threads in C++98:-). But I know what you
mean.) On the other hand, you should be able to implement most
of the interface in C98, with the exception of the movability
stuff.
Of course, it still fails to make detached and joinable
threads two distinct types
What do you mean by "detached thread"?
One that can't be joined. Under Unix, one on which you've
called pthread_detach. Under Windows (I think), one on which
you've closed all handles to it. In other words, the opposite
of a joinable thread.
---in fact, there's no need for a "type" for
detached threads, just a function to start them, and you
typically don't want copy or move semantics for the constructor
arguments for a joinable thread. Using the same basic interface
for both means we have a compromize. Depending on the use, the
use of copy semantics may make starting a joinable thread much
more expensive than necessary---this is certainly the case for
Boost, at any rate. I'm not sure how move semantics interact
with threads, so I can't say too much about the impact there.
Uh, are you saying that someone is seriously considering
/copying/ threads?
Not the object of thread type. But a thread executes code: in
C++, a functional object. And that gets copied (at least in
Boost). And that copy must occur in a thread safe manner; you
can't return from starting the thread (the constructor of thread
in the case of Boost and std::thread) before the copy has
finished, in the newly started thread. Which means (at least in
the case of Boost---there may be other solutions, but I'm not
familiar with them) an additional condition variable, and a
wait.
In the case of a joinable thread, this is typically not what is
wanted; the functional object will remain alive (but untouched
by the original thread) until after the join has finished, at
which time, the original thread will access the data in the
functional object which was modified by the joined thread. In
practice, the copy isn't a big problem; you just add a level of
indirection in the functional object (which contains a pointer
to the data object, rather than the data itself). But the extra
synchronization may have a performance impact on some systems,
e.g. in cases where threading is being used to parallelize
operations on a multi processor system.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34