On Jul 9, 2012, at 16:00 , John McCall wrote: >>>> From: Rick Mann <rm...@latencyzero.com> >>>> Subject: ARC and reinterpret_cast? >>>> Date: July 7, 2012 9:13:29 PM PDT >>>> To: Cocoa-Dev List <cocoa-dev@lists.apple.com> >>>> >>>> Hi. I'd like to write code like this: >>>> >>>> MyObject* foo = reinterpret_cast<__bridge MyObject*> (someVoidPointer); >>>> >>>> But the compiler doesn't like it. It's perfectly happy with: >>>> >>>> MyObject* foo = (__bridge MyObject) someVoidPointer; >>>> >>>> this is in a .mm file. >>>> >>>> The error is: >>>> >>>> error: type name requires a specifier or qualifier >>>> MyObject* me = reinterpret_cast<__bridge MyObject*> (inRefCon); >>>> ^ >>>> error: expected '>' >>>> MyObject* me = reinterpret_cast<__bridge MyObject*> (inRefCon); >>>> ^ >>>>> >>>> note: to match this '<' >>>> MyObject* me = reinterpret_cast<__bridge MyObject*> (inRefCon); >>>> ^ >>>> Is it a bug in the compiler, or am I doing something wrong? > > Well, it's definitely an ugly error message; that's worth a bug. > > The answer is that reinterpret_cast is redundant with __bridge. Bridging > casts are essentially a different kind of named cast: they document intent > more precisely than the general cast syntax, and they impose their own > well-formedness rules about the operand and result type. So you're not > getting any extra safety here. > > This is documented in the ARC specification: > http://clang.llvm.org/docs/AutomaticReferenceCounting.html#objects.operands.casts > 3.2.4. Bridged casts > A bridged cast is a C-style cast annotated with . . . > > In theory there's nothing preventing us from allowing these keywords on > named casts (although it would only be appropriate on reinterpret_cast), > but our sense is that doing so would only confuse the issue more by > suggesting subtle differences when none apply.
Well, more than anything, I wanted to keep consistent casting in my C++ code. While (__bridge Foo*) might be well-specified, it doesn't look it from the syntax. Maybe add bridge_cast<Foo*>()? Thanks for the clarification, in any case. -- Rick _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
