On Jul 12, 2011, at 12:51 PM, Kelvin Chung wrote:
> On Jul 12, 2011, at 2:13 AM, Greg Parker wrote:
>> On Jul 11, 2011, at 8:38 PM, Kelvin Chung wrote:
>>> It would be nice, for example, to see a hybrid class that can both call methods and receive messages. If an Objective-C class is built upon a C struct, why can't an Objective-C++ class be based on a C++ struct?
>> Because you'd have to break compatibility with either C++ or Objective-C. The first word of an Objective-C object is its isa pointer. The first word of a C++ object is its virtual table (if any). You can't have both, so somebody would have to break compatibility.
> I actually didn't read anywhere that the vtable pointer has to be the first member of a C++ object; in fact I read somewhere that it could be the last, or even different between implementations, or even not use vtables entirely. Based on that, I can't see why you can't have both. I have to acknowledge that in practice things may be different; I wonder why that is.
The standard does not require that it be first. But in today's implementation it is first. You could move it, but you would break binary compatibility. Like I said, you could do more if you were starting from scratch with no binary compatibility constraints.
> Another thing that comes into mind: it appears that as long as a C++ class is standard layout, has a nontrivial destructor (but stopping short of trivial), and all of its nonstatic members have the same restrictions (thus stopping short of POD) you could in theory "Objectivize" the C++ class with no problems (think of it as an Objective-C class that extends, from a C++ perspective, objc_object and possibly multiple "compatible" C++ classes). Is there something in the underpinnings of Objective-C++ that, in theory, prevent this?
Don't forget to disallow multiple inheritance. At that point it might work. There are still dozens of complications, of course (example: how do you integrate destructors and -dealloc).
At some point, you have to step back and examine the engineering cost and additional language complexity versus the potential gain to developers. We believe that Objective-C++ is great for gluing Objective-C and C++, and it's great for those who want Objective-C objects plus some of C++'s "better C" features, but that there's not enough benefit to be had from true large-scale integration of the two languages.
Greg Parker email@hidden Runtime Wrangler
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden