Re: why Obj-C
Re: why Obj-C
- Subject: Re: why Obj-C
- From: Michael Gersten <email@hidden>
- Date: Sun, 07 Apr 2002 23:18:23 -0700
I'll probably show my C++ limit on this one, but...
Andy Lee wrote:
>
>
At 9:02 PM -0800 4/4/02, Dan Crevier wrote:
>
>On 4/4/2002 8:46 PM, "Andy Lee" <email@hidden> wrote:
>
>
>
>> * "self" is really "self", by which I mean the method that gets
>
>> invoked for an object depends on the object's actual class at
>
>> runtime, unlike C++ where the method invoked depends on the
>
>> variable's declared type.
>
>
>
>Maybe I'm just missing what you are saying here, but this is the basic
>
>meaning of polymorphism, and is the way C++ works too. For example:
>
>
>
>class A
>
>{
>
> public:
>
> virtual void foo();
>
> void bar() { this->foo(); }
>
>};
>
>
>
>class B
>
>{
>
> public:
>
> virtual void foo();
>
>};
>
>
>
>void f()
>
>{
>
> B *b = new b;
>
> A *bAsA = b;
>
>
>
> bAsA->foo(); // calls B::foo()
>
> bAsA->bar(); // calls B::foo()
>
>}
First, does this compile? A *bAsA = B should provoke an error -- the two classes are incompatible.
Second, that it works is an accident of the virtual table. In C++, calling a virtual function is really calling the n-th offset (known at compile time) of a table. Which table might not be known until run-time, but either its address, or a pointer to its address, or a pointer to a pointer to its address (a function argument) will be known at link time. (ObjC really requires looking it all up at run time, at least the first time). In class A, foo is the first function in that table. In class B, if B had another virtual function defined before foo, it would not.
Michael
--
I am a Cocoa/WOF/EOF developer, and it looks like I'll be availble for hire. Please contact me at michael-job @ stb.nccom.com if interested.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.