[cfe-dev] GCC-specific, Clang-specific and ObjC-specific casts in C++
Sebastian Redl
sebastian.redl at getdesigned.at
Tue Jul 28 11:08:37 PDT 2009
Ken Ferry wrote:
> On Sat, Jul 25, 2009 at 3:17 PM, Daniel Dunbar <daniel at zuster.org
> <mailto:daniel at zuster.org>> wrote:
>
> On Sat, Jul 25, 2009 at 9:04 AM, Sebastian
> Redl<sebastian.redl at getdesigned.at
> <mailto:sebastian.redl at getdesigned.at>> wrote:
> > 4) Are there formalized Objective-C semantics? Which casts are
> allowed,
> > which are disallowed? Which are implicit, and which, in
> Objective-C++,
> > should be allowed by static_cast and reinterpret_cast respectively?
>
> Formalized, no. One general rule of thumb is that interface behave
> like pointers to structs, since this is historically their
> implementation. Of course, that doesn't always make a lot of sense so
> its mostly a good rule of thumb for what gcc will do, not what is
> necessarily best.
>
>
> There are a few people on this list who have lots of experience with
> ObjC and less with compilers.
>
> If you can phrase your questions in terms of objective-C code, we can
> answer them.
I'm afraid I know nothing about Objective-C, so I need someone who knows
both languages, at least to translate the questions. Here's the issue in
C++:
Given three classes, Base, Derived and Other, where Derived is derived
from Base and Other is unrelated to either, C++ allows the following
conversions:
Pointer to Derived -> Pointer to Base: implicit conversion, always safe
(except in some obscure multiple inheritance cases).
Pointer to Base -> Pointer to Derived: explicit and unchecked via
static_cast, requires the programmer to know what he's doing, or
explicit and runtime-checked via dynamic_cast.
Pointer to Base <-> Pointer to Other: explicit and unsafe via
reinterpret_cast, overrules any type safety there is
I expect that you can convert pointers to related interfaces
(protocols?) and classes in Objective-C as well, and I wonder how
Objective-C++ should treat attempts to cast Obj-C types via C++ cast
operators.
Sebastian
More information about the cfe-dev
mailing list