This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Minor problem messaging C++ wrappers in Objective-C with gcc4.2


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;
  	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 */
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 */

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

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:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]