function pointers & classes

Started by
25 comments, last by _DarkWIng_ 21 years, 5 months ago
quote:Original post by Matt Calabrese
If that is true, then what is the standards claim on polymorphism through "method pointers?"

In what way? The C++ Standard describes the semantics that a programmer can expect from dynamically resolved function calls (BTW, "method" is the incorrect terminology for C++). There is no attempt to impose an implementation mechanism.
quote:
Compilers should be free to their own implementation, but whether or not method pointers work with polymorphism should not.

That''s about right.
quote:
What if you don''t want dynamic linking on an object through a method pointer call?

Since the Standard has nothing to say about linking issues, I''ll assume you mean dynamic despatch. If you don''t want dynamic despatch, you don''t make a function virtual.
Advertisement
quote:Original post by _DarkWIng_
I''ve got a class and one of the functions takes as a parameter a function pointer. This works just fine if that function is some global one. But if it''s a member of another class the it just doesn''t work. Any idea how to solve this?


class Cubemap {
void RenderToCubemap( void (*renderFunction)(void) );
...
}

this works:
Cubemap cm
cm.RenderToCubemap( someGlobalFunction );

but this doesn''t
cm.RenderToCubemap( someOtherClass.publicFunction );


You should never let your fears become the boundaries of your dreams.


Can''t you make the publicFuntion a friend-function to someOtherClass?

quote:Original post by SabreMan
(BTW, "method" is the incorrect terminology for C++).

I've always been told to call them methods, and in all of the books I've read they call them methods. What should I call them? Just member functions? (no that wasn't sarcastic, I really am curious if there is a reason not to call them methods because I have specifically been taught TO call them methods)
quote:
Since the Standard has nothing to say about linking issues, I'll assume you mean dynamic despatch. If you don't want dynamic despatch, you don't make a function virtual.
Yup, I meant dispatch, I clarified that in my previous response, though this topic is rather active you prolly replied before then.

However -- you missed my point. There are times that you call a virtual function like this:


  #include<iostream>class A{public:    virtual void Foo() { std::cout << "Parent\n"; }};class B    : public A{public:    virtual void Foo() { std::cout << "Child\n"; }};int main(){    B Something;    Something.A::Foo(); // This is what I'm refering to!                        // You explicitly call the 'A'                        // version of Foo, which is impossible                        // to do with member function pointers                        // because dynamic dispatch is assumed    return 0;}  


Get it?

EDIT: Added function bodies to make my point more clear

[edited by - Matt Calabrese on November 9, 2002 8:38:02 AM]
quote:Original post by Matt Calabrese
I''ve always been told to call them methods, and in all of the books I''ve read they call them methods.

C++ books? The only one of my C++ books which mentions "method" in the index is Advanced C++ (Coplien) and does so with regard to Smalltalk, not C++.
quote:
What should I call them? Just member functions?

Yep.
quote:
However -- you missed my point.

Yes, sorry.
[snip example]

Get it?
Yes, I see what you mean and you''re right. However, the thinking seems flawed. When you mark a function "virtual", you are saying to the compiler "despatch this method on the dynamic type of the first argument". The fact that using the dot operator actually performs static resolution is a bit of an anomaly (possibly even bogosity). So, you seem to be saying both "do dynamic despatch" and "do static despatch" which is a rather odd thing to want to say. You would avoid this sort of problem by not weaving such an ambiguity into a design, so I think it''s an artificial problem. To be a *real* problem, it has to prevent you from solving real-world problems in an effective manner.
In Java you call them methods and in C++ you call them functions. I seem to remember that calling member variables, attributes, is something that got introduced with Java as well.
quote:Original post by philscott
In Java you call them methods and in C++ you call them functions. I seem to remember that calling member variables, attributes, is something that got introduced with Java as well.


I''ve never learned Java so I''m not picking it up from there, some sources that actually call them methods that I learned from are: C++ for Engineers and Scientists
by Gary J. Bronson; the online reference that so many people here refer to at http://www.parashift.com/c++-faq-lite/ and all of my teachers call them methods despite the fact that they don''t know java and have been in the industry for a very long time. I think that saying "calling them methods is wrong in C++" is hogwash. Maybe Java was the first language to call them that, but that''s how they''re often now referred to in C++. From what I''ve seen, it''s an accepted term to use and it''s shorter than saying "member function." Arguing that it''s wrong to call them methods is just silly.
I can see where this discussion is headed, so I''m wary of posting anymore on the topic. But, what the hell...

quote:Original post by Matt Calabrese
I''ve never learned Java so I''m not picking it up from there, some sources that actually call them methods that I learned from are: C++ for Engineers and Scientists
by Gary J. Bronson; the online reference that so many people here refer to at http://www.parashift.com/c++-faq-lite/ and all of my teachers call them methods despite the fact that they don''t know java and have been in the industry for a very long time.

None of those are official sources. The C++ Standard does not mention methods, Stroustrup doesn''t call them methods, and none of the Stroustrup-edited AW books call them methods.
quote:
I think that saying "calling them methods is wrong in C++" is hogwash.

No - it''s technically accurate.
quote:
Maybe Java was the first language to call them that

No, it wasn''t. I suspect Simula might have been.
quote:
but that''s how they''re often now referred to in C++.

By people who are complacent with accuracy of terminology.
quote:
From what I''ve seen, it''s an accepted term to use and it''s shorter than saying "member function." Arguing that it''s wrong to call them methods is just silly.

You''re entitled to your point of view, but I don''t share it. My view is that it is worthwhile s/w developers being accurate in terminology. Commonly understood and well defined terms enable communication, and "method" is not a well defined term in the world of C++.

This topic is closed to new replies.

Advertisement