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
