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