[OT] Re: [gtkmm] Re: pthreads with gtk/gtkmm



>> 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]