[OT] Re: [gtkmm] Re: pthreads with gtk/gtkmm
- From: Paul Davis <paul linuxaudiosystems com>
- To: Leslie Polzer <sky nachtwind net>
- Cc: gtkmm-list gnome org
- Subject: [OT] Re: [gtkmm] Re: pthreads with gtk/gtkmm
- Date: Wed, 19 Feb 2003 08:35:35 -0500
>> i follow the guideline i outlined above because it appears to me that
>> any cast from void * to anything at all is 100% dangerous, and using
>> static_cast<> suggests that it is somehow "safe" when in fact it is
>> not.
>I don't get this point. I mean, architectural differences regarding data
>types, sure - but when you come into a situation where you must use a
>void* to pass around data, you know what you get because you are the one
>defining the void* when invoking the function (ok, this may be different
>when a loosely organized bunch of people are coding different parts of
>the program and the interfaces are not clearly defined; but in this case
>the problem isn't caused by inappropriate casts).
i agree with you about that, but it remains a problem and its not
aided in any way by using static_cast<>. also "the interfaces are not
clearly defined" applies to any situation where void * must be used
because you are forced to abandon type safety. its not necessarily a
reflection of a design or development process error as you imply:
there are situations where this is necessary - i just feel that using
reinterpret_cast<> serves as a reminder that neither we nor the
compiler have any clue whatsoever what the void * actually is.
>[1] http://www.cs.rpi.edu/~wiseb/xrds/ovp3-1.html
i suppose that one can argue, as this paper implicitly is doing, that
the cast between void* and Anything* is built into the language. thus
static_cast<> is right because we are performing a completely ordinary
cast between two pointer types that are defined as convertable by the
language: its a "standard conversion".
however, that paper, like stroustroup, focuses on static_cast<> to do
class navigation between parents and children, and it is in this spirit
that i limit my use of static_cast<> to such situations.
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]