Quote:
Originally Posted by Soulstorm
Correct me if I'm wrong, but I believe ObjC classes derive from NSObject, not an object of type id. Some Cocoa classes do not even derive from that.
|
Catch is there are different variants of Objective C, from different vendors. So there are variations in this sort of thing. What you're describing is Apple's take on it (which is admittedly the most common one).
Quote:
Originally Posted by Soulstorm
And I don't think that NSArray rely on what you said to hold any type of class. I think it relies on the fact that none of the class the programmer creates is treated internally like C++ treats it's own classes, since all classes are created using pointers. The compiler knows what type of class you created when it sees it's name, but it actually allocates the memory manually (with the inherited -alloc function).
|
The closest equivalent, in C++ would be a programmer being able to make assumptions about how the compiler implements types (eg the layout of bits in an int or float, the layout of classes and structures, etc etc). The catch is that the C++ standard deliberately leaves those things up to the implementer of the C++ compiler. The C++ programmer who relies on particular implementation of types will, invariably, write code that works with a particular compiler, but will not be guaranteed to work with other compilers.
Quote:
Originally Posted by Soulstorm
So, an NSArray does not contain any object, but just pointers to classes, that have been manually allocated elsewhere. And that's why I believe this pattern can be simulated in C++.
|
I'm not arguing with you there. In fact an early version of GNU's implementation of Objective C was just a preprocessor that output code which is fed directly to the GNU C compiler. But that sort of implementation relies on specific knowledge of how the C compiler does business.
So, if you wanted, it is definitely feasible to write a Objective C interpreter/compiler or library in C or C++.
What is less feasible is providing equivalent functionality for a C++ programmer which, from your wording, I assumed was what you were about. One characteristic of a C++ compiler is that, at run time, most type information is unavailable. So there is no technique in C++ that allows calling an arbitrary method of an object, given only the name of the method as a string (there are techniques to call specific methods, by use of a map construct, but that relies on entries being explicitly placed in the map before attempting to use it). The core of the difference is that C++ is a statically typed language (meaning that the program cannot directly access, at run time, information about the type of an object or methods it provides) in contrast to Objective C which is dynamically typed (meaning that, given an arbitrary object, information about its type and methods can be queried at run time). Which means that, given an object in an NSArray, it is possible in Objective C to directly access information about the type and methods it supplies. This is not possible, in C++: to simulate such a thing, it is necessary to do lots of extra bookkeeping (of the type information, of information about the methods) and to accept some constraints on ability to do that with some types but not others.