GCC-specific, Clang-specific and ObjC-specific casts in C++

Hi,

I just committed a patch that does correct validation of C-style casts for C++. However, it is only correct as far as the standard is concerned. Clang does more. To implement this, however, I need information.

1) Do we want to support GCC's cast-to-union in C++? I think not.
2) Should casts to ExtVector types be implicit, static_castable, or only reinterpret_castable? Are there formalized semantics, or should I just go by the CheckExtVectorCast code?
3) Same for Vector types.
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?
5) Did I forget anything?

Sebastian

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?

There is no spec. for Objective-C++ when it comes to c++ specific type-casting
syntax. We are pretty much at the mercy of underlying implementation in g++.
But as our C++ side of the story progresses, we may want to think about this and
spec. out what the rules should be.

- Fariborz

1) Do we want to support GCC's cast-to-union in C++? I think not.

No; I think it's okay to leave that as a C-only hack. It would
actually be difficult because it might affect SFINAE.

2) Should casts to ExtVector types be implicit, static_castable, or only
reinterpret_castable? Are there formalized semantics, or should I just
go by the CheckExtVectorCast code?

Scalar->vector splats should be implicitly legal. static_cast should
probably work the same way for scalar->vector. reinterpret_cast
should probably act like a bitcast. For vector->vector, there
shouldn't be any implicit casts or static_cast; reinterpret_cast
should probably bitcast the vector. These are all guesses, though;
note that the ExtVector semantics are supposed to be based off of
OpenCL.

3) Same for Vector types.

No implicit or static casts, reinterpret_cast == bitcast, I think.
You could compare with g++, though.

-Eli

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.

- Daniel

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.

-Ken

Ken Ferry 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

Protocols in Objective-C are just objects (instances of the Protocol class) so they don't need any special handling.

There is no multiple inheritance in Objective-C, so any related issues are not present.

Casting a derived class to a superclass can happen implicitly, as can casting to id (or Class if it's a class).

The GCC behaviour causes an error if you attempt to use static_cast to cast from a pointer to one class to a pointer to an unrelated class. This seems sensible.

The GCC behaviour allows you to use static_cast to cast from a pointer to one class to a pointer to a subclass. This seems sensible.

The GCC behaviour allows you to use reinterpret_cast to cast from anything (including int) to an Objective-C pointer type. This seems to be equivalent to a C-style cast (which is also permitted).

There appears to be a bug in GCC's Objective-C++ handling[1]. If you pass a pointer to an object to a function that takes a subclass as an argument, then GCC silently performs an implicit cast in Objective-C++ mode issues a warning in Objective-C mode. This may simply be due to different default warnings. This is probably not behaviour that we want to copy.

To be honest, I doubt this is very important. I'd be surprised if anyone is relying on specific behaviour of this corner case; Objective-C++ is mostly used for Objective-C wrappers around C++ libraries (and is basically unmaintained in the GCC tree, so no one with any sense is using it anywhere other than OS X).

David

[1] i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5484)

Hi Sebastian et.al.,

I just had a brief chat with Doug on this topic...I think it's best to defer this issue for now.

At some point, Doug, Fariborz, and I will need to discuss how ObjC will fit with C++ casts.

Until C++ is more complete, it's not worth worrying about.

snaroff