Here's an outline of a my idea for a general solution to a C++ interface to Cocoa. To sum it up: A Better Objective-C++.
Using "ABObjCpp", you'd b eable to use all of the existing Cocoa classes as C++ classes.
The problem with Objective-C++ is that Objective-C objects and C++ objects are separate. So I propose ABObjCpp. The key improvement are:
1. C++ classes can be instantiated as Objective-C objects and Objective-C classes can be instantiated as C++ objects.
2. Objective-C objects can provide a C++ interface and C++ objects can provide an Objective-C interface.
3. C++ objects will be extended to support the dynamic capabilities of Objective-C objects. For example, there would to some syntax used to send messages to C++ objects (in addition to the normal syntax for calling functions). Ideally, normal Objective-C messaging syntax could be used. For example, given o is a C++ interface to an instance of a class with a method "draw". To call the method directly, you'd write "o.draw()". To send the draw message to the object, you'd write "[o draw]". If the method is know at compile time, you'd be able to use either syntax. If the method is not know at compile time, the first syntax would generate an error when compiled, so you'd have to use the second syntax.
Since there is overhead in supporting these capabilities, it probably makes sense to provide a way for a class (of either flavor) to opt out. (Or, to be more conservative, require that a class opt in.)
It might be possible to implement some form of ABObjCpp as a preprocessor on top of Objective-C++ (although, it might be useful to use a different syntax than I show in my examples--not sure about that).
An Example:
Consider:
This shows that an Objective-C class declared with name <name> can be instantiated as a C++ class using name _cpp_<name> and that a C++ class declared with name <name> can be instantiated as an Objective-C class using the name _objc_<name>.
It also shows that C++ objects supporting messaging syntax.
It also shows that C++ objects implicitly have a method called _objc_interface() that returns an Objective-C reference to the object and that Objective-C objects implicitly support respond to a message called _cpp_interface that returns a C++ reference to the object.
Obviously, there are a lot of tricky details to this. Memory management, for one. Mapping between init methothds and contructors. Plus many, many more. But it should be possible to create a useful ABObjCpp. I think it's possible to do it as a preprocessor on top of the existing Objective-C++, which would make it easier to implement.
Edit: By the way, I'm thinking that the C++ version of an Objective-C class would be as a proxy generated by the preprocessor. So, for my "foo" Objective-C class abouve, the generated C++ code would be something like this:
Every method declared in the Objective-C interface will be implemented as a passthrough in the generated C++ class.
Using "ABObjCpp", you'd b eable to use all of the existing Cocoa classes as C++ classes.
The problem with Objective-C++ is that Objective-C objects and C++ objects are separate. So I propose ABObjCpp. The key improvement are:
1. C++ classes can be instantiated as Objective-C objects and Objective-C classes can be instantiated as C++ objects.
2. Objective-C objects can provide a C++ interface and C++ objects can provide an Objective-C interface.
3. C++ objects will be extended to support the dynamic capabilities of Objective-C objects. For example, there would to some syntax used to send messages to C++ objects (in addition to the normal syntax for calling functions). Ideally, normal Objective-C messaging syntax could be used. For example, given o is a C++ interface to an instance of a class with a method "draw". To call the method directly, you'd write "o.draw()". To send the draw message to the object, you'd write "[o draw]". If the method is know at compile time, you'd be able to use either syntax. If the method is not know at compile time, the first syntax would generate an error when compiled, so you'd have to use the second syntax.
Since there is overhead in supporting these capabilities, it probably makes sense to provide a way for a class (of either flavor) to opt out. (Or, to be more conservative, require that a class opt in.)
It might be possible to implement some form of ABObjCpp as a preprocessor on top of Objective-C++ (although, it might be useful to use a different syntax than I show in my examples--not sure about that).
An Example:
Consider:
Code:
@interface foo
{
int x;
}
-(id) init;
-(int) accumulate:(int) value;
@end
@implementation foo
-(id) init { self = [super init]; if (self) { x = 0; }; return self; }
-(int) accumulate:(int) value { x += value; return x; }
@end
class bar
{
int y;
public:
bar() { y = 0; }
int subtract(int value) { y -= value; return y; }
};
int main()
{
// foo used as an Objective-C class
foo* a = [[alloc foo] init];
[a accumulate: 7]; // a.x is 7
// foo used as a C++ class
_cpp_foo b; // notice the C++ version of the Objective-C foo class is called _cpp_foo;
b.accumulate(5); // b.x is 5
[b accumulate: 10]; // b.x is 15
// bar used as an Objective-C class
_objc_bar* c = [[alloc _objc_bar] init];
[c subtract: 10]; // c.y is -10
// bar used as a C++ class
bar d;
d.subtract(-1); // d.y is 1
// accessing b via an objective-C interface:
foo* b2 = b._objc_interface();
[b2 accumulate: 50] // b.x is 65--b2 refers to the same instance as b.
// accessing c via a C++ interface
bar& c2 = [c _cpp_interface];
c2.subtract(1); // c2.y is -11--c2 referes to the same instance as c.
... (cleanup code omitted)
}This shows that an Objective-C class declared with name <name> can be instantiated as a C++ class using name _cpp_<name> and that a C++ class declared with name <name> can be instantiated as an Objective-C class using the name _objc_<name>.
It also shows that C++ objects supporting messaging syntax.
It also shows that C++ objects implicitly have a method called _objc_interface() that returns an Objective-C reference to the object and that Objective-C objects implicitly support respond to a message called _cpp_interface that returns a C++ reference to the object.
Obviously, there are a lot of tricky details to this. Memory management, for one. Mapping between init methothds and contructors. Plus many, many more. But it should be possible to create a useful ABObjCpp. I think it's possible to do it as a preprocessor on top of the existing Objective-C++, which would make it easier to implement.
Edit: By the way, I'm thinking that the C++ version of an Objective-C class would be as a proxy generated by the preprocessor. So, for my "foo" Objective-C class abouve, the generated C++ code would be something like this:
Code:
class _cpp_foo
{
private:
foo* _objc_object;
int x;
public:
_cpp_foo() { _objc_object = [[alloc foo] init]; }
~_cpp_foo() { [_objc_object release]; }
int accumulate(int value) { [_objc_object accumulate: value] }
};Every method declared in the Objective-C interface will be implemented as a passthrough in the generated C++ class.
. KVC is also the core for bindings, which means if this doesn't work with a C++ object, bindings don't either.
