Re: Does object have function?
 
"Paul N" <gw7rib@aol.com> wrote in message 
news:6ef28ebb-f758-4263-95c8-9b3aef8736a4@j18g2000yqd.googlegroups.com...
On 29 Oct, 01:21, Rui Maciel <rui.mac...@gmail.com> wrote:
Jim Langston wrote:
What I am trying to accomplish: I have a map of polymorphic objects and
these objects may have certain methods defined or not. If the instance
has the method then I want to call it, otherwise not.
It is trivial to create a virtual function for a few functions. But I
would have to add every single function that could be interfaced.
I would just to somehow be able to tell if an instance has a function
available. Consider:
It would be much easier to do something like:
<code>
class Base {
public:
virtual void foo() { //do nothing}
};
class DerivedOne : public Base {
public:
void foo() { //do something }
};
class DerivedTwo : public Base {
public:
void foo() { //do something}
};
class DerivedThree: public Base {
};
int main(void) {
Base* bps[3];
bps[0] = new DerivedOne();
bps[1] = new DerivedTwo();
bps[2] = new DerivedThree();
for ( auto i = 0; i < 3; ++i )
{
thisOne->foo();
}
return 0;}
</code>
<Quote>
I'm not an expert but I'd recommend this technique as well. Just one
thing to add - if you find yourself adding the same "foo" function to
more than one derived class, consider whether you could introduce it
in a single class and derive the others from it.
Just my two pence...
Paul.
</Quote>
Off topic: I sure wish Microsoft could figure out how to freaking quote 
messages right.  Tried using Microsft Live Mail and it does the exact same 
thing, no '>' character.
On topic: This is actually the way I wound up implementing it, but I'm still 
not happy with the design.
My form is derived from the functionality I want which is this:
In my program I have a collection of objects in the world.  These objects 
can be anything and I derive from a base class so I can put the objects in 
the same collection.
Now, any object that has a model should have a functioning display routine. 
So I simply iterate through (or choose a specific) object then try to 
display it.  A function object won't necessarily have a display routine 
(unless I add one representing a function somehow.  Maybe a big f()).
My intention to hold ambigious data in one container stems from the fact 
that these objects will be created by the end user by various means.  A 
sphere, a function, a ball, a race car, a web address, whatever types can be 
created.
Now when I display the user space I want to iterate over these objects and 
display any that are displayable.
For this first use it is relatively easy and the solution here works but not 
as well as I'd like for my purposes.
In the future I may wish to do other things to objects, if it's a function 
to call the function with some parameters (which will probably also be 
stored in objects).  Then I'll have to add antoehr virtual function to base. 
And another.  And another.  And eventually base will be a humongous class 
with thousands of possible calls that can be called on each object.
I would rather be able to simply say:
   std::map<std::wstring, jglObject>::iterator it = /*a valid map location*/
   (*it).display();
But as it is I can't unless I've created display in base as a virtual 
function.
Yes, I am fully aware that this is dangerous for the reason that I presume 
..display() is going to display the object in OpenGL in my current window, 
but perhaps this is not a model, but soemthing else and .display() just 
happens to have the same name and breaks code when I execute it.
This is most likely the reason C++ doesn't do what I want it to do, strong 
typing.
In reality doesn't the system know that (*it) points to a jglModel or 
jglSphere which both have a .display() function?  Without the virtual in 
base I have to try to cast to every type that has a .display() to see if it 
has it.
I am not sure if there is, currently, a [better] solution to my problem or 
not.  I am just not happy with the current state of affairs.  Unless someone 
can suggest a better design that gets rid of this "problem".
Regards,
Jim Langston