|
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
#16
|
|||
|
|||
|
it's what one third of this board is about! - C, C++ and Obj-C.
it's a language - another object oriented version of c, like c++ or java. it's been round for quite a while i think - compilable by the gcc compiler. not owned by anyone in particular i don't think. reason i'm interested in it is because it's used in one of apple's os x dev options (cocoa) - objective-c is the main language used in it. it seems to be a pretty clean simple small extension to c - and allows for a lot of dynamic looseness to go on it looks like. not sure to what extent the looseness/flexability is embedded in the obj-c language itself or if the flexability comes from the way it's implimented into os x's runtime system - bit of both probably. it does certainly seem more flexible than c++. if you had to take c, and make a simple and small o.o. version of it, with flexability being a priority, obj-c might be similar to what you'd come up with. (i guess) it's also why i started to learn c. here's a few obj-c links: http://www.foldr.org/~michaelw/objective-c/ http://manila.mems.rice.edu/developer/tools/objective-c http://www.toodarkpark.org/computers/objc/ Last edited by balance : March 20th, 2003 at 09:03 AM. |
|
#17
|
||||
|
||||
|
Quote:
-hmm, i think i can answer the first part of your question if i am understanding it right. Let me give u an example of how u can have an array with different object types. U start of by declaring an abstract class, lets call it Shape. Then, from Shape, u derive Line, Circle, and Square. The root of polymorphism lies in the fact that a base class pointer can point to a child class. So, if u made a Shape ptr, it could then point to Line, Circle, or the Square class. So, what u can do is this: Code:
Shape* sPtr[2]; Line line1(3,5,2,5,L); Circle circle1(4,2,1,C); sPtr[0] = &line1; sPtr[1] = &circle1; for(int x = 0; x < 2; x++) sPtr[x]->draw(); -so u have a pointer array pointing to 2 different objects, and accessing the draw() function which is defined slightl differently in the Line and Circle classes. |
|
#18
|
|||
|
|||
|
Sorry, i think you missed the point. The question was how to implement my pseudo-code "if object is AClass".
I know this from Delphi, there it is actually this syntax and it does work. But how about C++? Is there no way to find out the class of an object after you created it? I mean, as workaround, you could make a CMyClass::type property, but this canīt be all about it...???
__________________
-- Manuel Hirsch - Linux, FreeBSD, programming, administration articles, tutorials and more. |
|
#19
|
|||
|
|||
|
There isn't any inherrent run-time type checking that you can do in C++. MFC implements a mechanism through CObject using CRuntimeClass and the RUNTIME_CLASS macro.
A quick glance at the MFC literature shows that the actual class name is stored, the size of the object, a pointer to the constructor of the object, and a pointer to the base class (singular, since MFC doesn't play well with multiple inheritance), along with a few other parameters specific to CObject implementation. If you were to implement a typechecking scheme, you'd probably need to do much the same. |
|
#20
|
|||
|
|||
|
infamous41md,
The question I posed was whether polymorphic behavior can be implemented without using polymorphism i.e. since polymorphism is like an internal switch statement, can you just write a switch statement and get the same behavior. Your code doesn't answer the question becaust it employs polymorphic behavior by using a base class pointer. At this point, I'm beginning to think you can't write a switch statement that will duplicate polymorphic behavior in C++. balance, Thanks for the explanation. Last edited by 7stud : March 20th, 2003 at 03:29 PM. |
|
#21
|
|||
|
|||
|
...or maybe I should have said, you can't very easily write a switch statement that will duplicate polymorphic behavior in C++.
|
|
#22
|
||||
|
||||
|
Quote:
Actually there has been one around for quite a while -- it's called the typeid operator. Some vendors didn't implement it in the beginning though, and I think Microsoft implemented their version before the C++ Standard was set in stone (they implement the standard method as well now). For example: Code:
#include <iostream>
#include <typeinfo>
class Class1 { };
class Class2 : public Class1 { };
int main () {
Class1 *a;
Class2 b;
if (typeid(a) != typeid(b))
{
cout << "a is: " << typeid(a).name() << endl;
cout << "b is: " << typeid(b).name() << endl;
}
return 0;
}
See http://msdn.microsoft.com/library/d.../express_78.asp and http://www.ictp.trieste.it/~manuals...g/RTTI.doc.html for more info |
|
#23
|
|||
|
|||
|
Quote:
no problemi take it that no one does then :/ (know objective-c that is). oh well, not to worry. maybe this forum title should loose the obj-c bit? (no need to answer that - just a thought). |
|
#24
|
||||
|
||||
|
IIRC, the first use of Objective-C that I remember was for the NeXT computer. The OS was written in Objective-C and it came with a compiler as well. For those of you who are relatively young, NeXT was the company founded by Steve Jobs after he was ejected from Apple. They made computers way ahead of their time (Their machine had a rewritable optical drive in 1987!)
[edit] Adding link: http://www.channelu.com/NeXT/Black/index.html for those of you who want a piece of history[/edit] Last edited by Scorpions4ever : March 20th, 2003 at 04:03 PM. |
|
#25
|
|||
|
|||
|
Thanks, I'd never run across the typeid function/operator.
|
|
#26
|
|||
|
|||
|
Scorpions4ever,
The typeid() fucntion is even in my book in the chapter on polymorphism--I missed it. There goes that theory on why polymorphism is so powerful. Can you explain why? |
|
#27
|
||||
|
||||
|
Quote:
Actually, as I recall the description I read over a decade ago, polymorphism is implemented through a virtual method table (VMT) with function pointers. The pointer to a virtual method is stored in the VMT -- I guess a NULL is stored for a pure virtual method. Then if a derived class has its own version of that virtual method, its pointer goes into the VMT instead. Then during execution, you use the address in the VMT just as you would in a jump table. The OOP supplement (the thin manual) that came with Turbo Pascal 5.5 was my introduction to OOP and it explained the mechanics of implementing OOP very well. Other than that, my two-cents worth is that I have found polymorphism useful, though I haven't been able to use it much for the past eight years because almost all of my work is in embedded C. My classic example was before I finally bit the bullet and accepted that I would need to learn Windows programming. I had been developing my own TUI interface patterned after Borland's IDE. After working out doing pop-up windows, I wrote the pull-down menu system in Turbo Pascal using top-down structured programming. The code was complicated and pretty much worked, except that there were a few nagging bugs that I couldn't work out. Then I learned C++, after which I converted my TUI to C++ using OOP. The design went together very easily, was a lot cleaner, and didn't have those nagging bugs. But then I had to drop that project when I started learning Windows programming. |
|
#28
|
||||
|
||||
|
Quote:
Sorry, was busy for most of the day. I really hadn't paid attention to what this thread was about and had to reread what everyone had said. Anyways, I think MJ Eggertson did a pretty good job explaining what polymorphism does. One of the major advantages is that it promotes code reusability. Let's discuss a semi-real situation to see how this works: In an object framework, such as Borland's Visual Component Library (VCL), somewhere deep within the framework is a handler for the WM_PAINT message, which (conceptually) looks something like this: Code:
for (int i=0, i < form->components->count; i++) form->components->component[i]->Repaint(); All it does is go through the list of components on the form and calls the function to repaint each one of them. Now, it happens that all the visual component classes (TButton, TEdit, TPanel etc.) are descended from the TWinControl class and so they all have Repaint() methods. Each Repaint method for each class has different code, depending on whether the class is a button, text box, panel etc. However, the code that handles the WM_PAINT message doesn't really care, because it is depending on polymorphism to take care of it. If you had to do this with a switch statement, the code would look something like this (again conceptual code here, not actual code): Code:
for (int i=0, i < form->components->count; i++) {
component = form->components->component[i];
switch (component.type)
case tbutton:
TButton(component)->Repaint();
break;
case tedit:
TEdit(component)->Repaint();
break;
...
}
This means a lot more code for the person writing the WM_PAINT handler, because they have to put code for every possible control class (and there are a lot of windows controls!). Not only that, if you were to write your own custom component (say an LED control), you'd have to go fiddle with their code and add the necessary code to repaint your new control. Now, if they release a newer version of their library (note that they haven't met you and don't know about your super-duper LED control), they won't have the code to handle your control. So, you'll need to go and fix their code again to handle your new control and so on -- we're talking mucho maintenance nightmare. With polymorphism, all you need to do is ensure that your control class is descended from the TWinControl class and implement the Repaint method as needed for your class. You don't need to touch a single line of their code. They can alter their code whenever they like and it won't break any of your code. Do you see the obvious advantages? ![]() Hope this makes sense ![]() |