Bus error gcc compiler for any for ( x in array ) inside Objective-C++ template
John Holdsworth
mac@johnholdsworth.com
Thu Oct 15 09:32:00 GMT 2009
Hi,
I've encountered a bus error using Apple's gcc in Xcode 3.1, 3.2
compiling the following code or any containing for( x in y ) is used
inside a template in Objective-C++.
template <typename ETYPE>
class OODictionary {
void boom() {
NSArray *keys = nil;
for ( NSString *key in keys ) {
}
}
};
I've not been able to build with a more recent gcc so I can't tell
if it is still present but figure I'd better let you guys know.
Thanks,
John H.
http://objcpp.johnholdsworth.com
On 8 Sep 2009, at 21:30, John Holdsworth wrote:
> Hi,
>
> I've found it very useful to be able to use C++ to extend Objective-C
> using a little judicious operator overloading and I notice that
> gcc-4.2
> now automatically "unboxes" wrapper classes with no warning when
> they are messaged - provided an appropriate cast is available.
>
> For example:
>
> class AStringClass {
> NSMutaableString *str;
> public:
> AStringClass( NSMutableString *str ) {
> this->str = str;
> }
> operator NSMutableString * () {
> return str;
> }
> };
>
> This class can now be messaged in gcc4.2 as below without a warning:
>
> AStringClass aString( nil );
> [aString doubleValue];
>
> Unfortunately is can also be sent a message which the compiler
> is in a position to know is not available given the only cast
> available was to a NSMutableString:
>
> [aString count]; // not a valid method for NSMutableString *
>
> This happens as internally as there is an implicit cast to type "id"
> in
> ${GCCROOT}gcc/objc/objc-act,c, function: objc_finish_message_expr
>
> /* APPLE LOCAL begin decay function/array receivers */
> #ifndef OBJCPLUS
> /* In C need to decay array/function receivers so can be converted
> to id. */
> struct c_expr exp;
> exp.value = receiver;
> exp = default_function_array_conversion (exp);
> receiver = exp.value;
> /* APPLE LOCAL begin radar 3533972 */
> #else
> if (can_convert_arg (objc_object_type, TREE_TYPE (receiver),
> receiver, LOOKUP_NORMAL))
> {
> /* In rare cases, 'receiver' must be converted to type 'id'
> using
> user-defined type conversion. 'id' is type of the 1st
> argument to
> objc_msgSend (id self, SEL op, ...); */
> tree cnv_rec = perform_implicit_conversion (objc_object_type,
> receiver);
> if (cnv_rec && cnv_rec != error_mark_node)
> return objc_finish_message_expr (cnv_rec, sel_name,
> method_params);
> }
> /* APPLE LOCAL end radar 3533972 */
> #endif
>
> Would it not be possible for the implicit conversion retain the type
> which it was forced into using when searching for a match for "id"
> and using this as the type of the receiver of the message rather
> than "id". I've looked and the code but can't quite get to where
> the change (probably quite a small one) would need to be made.
> Perhaps even, this is already fixed...
>
> Can anybody help?
>
> John Holdsworth
> objcpp.johnholdsworth.com
>
>
> On 8 Apr 2009, at 14:34, David Ayers wrote:
>
>> Am Samstag, den 21.03.2009, 11:59 +0100 schrieb John Holdsworth:
>>
>>> I was wondering if it would be a useful extension to Objective-C
>>> expand the [] operator
>>> to support array and hash references to NSArray and NSDictionary
>>> classes directly to
>>> greatly improve the readability of code:
>>
>> I'm not an ObjC front end maintainer and have no authority but one
>> issue
>> I would have with this feature with gcc proper is that the ObjC front
>> end would have to learn about the semantics of "NSArray" and
>> "NSDictionary" which are actually not part of the language but part
>> of
>> an external library.
>>
>> Now gcc already supports the -fconstant-string-class option as one
>> way
>> to embed knowledge about an external library into an executable.
>> But I
>> would like adding options with all these semantics from a foreign
>> library into the language implementation.
>>
>> Maybe this could be done more elegantly with plugin infrastructure
>> that
>> that es being currently added: http://gcc.gnu.org/wiki/plugins
>>
>> Cheers,
>> David
>>
>>
More information about the Gcc
mailing list