Well that's just stupid isn't it?
It's a derived class, so the base classes members are also the derived classes members. The classes are related somehow and the signatures are the same.
Guess I'll just have to abandon the project.
Well that's just stupid isn't it?
It's a derived class, so the base classes members are also the derived classes members. The classes are related somehow and the signatures are the same.
Guess I'll just have to abandon the project.
Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)
This sentence makes no sense whatsoever. Why would you think a viewPort is also a vSpec? (And for that matter, it doesn't work the other way around either: a vSpec isn't a viewPort -- it may be built on top of a viewPort, yes, but they are not actually the same thing.) If you mean that a vSpec contains all the same things as a viewPort, yes that's true, but the whole point of vSpec::aPlot is that it can access all the new stuff in vSpec and thus claiming that it should somehow be the same as a viewPort:: function is just silly. My understanding is that you think this should work, somehow:Originally Posted by samGwilliam
If this isn't what you want, well I don't know what you want then, because there's no other reason to have a pointer to member function.Code:class viewPort { //... stuff ... void aPlot(int, int, unsigned long); }; class vSpec : public viewPort { //... stuff ... void aPlot(int, int, unsigned long); }; viewPort vpobject; void (viewPort::*funcp)(int, int, unsigned long); funcp = dynamic_cast<viewPort::*>(&vSpec::aPlot); //this is the line you want to use (for some appropriate cast) vpobject.*funcp(2,3,4L); //what the heck is this going to DO?
True...
And back to madness.
My suggestion would be to temporarily put the project on hold and read a book, or at least a couple of chapters.
Well it allowed: viewPort *v = new vSpec; so there is some degree of interchangabliliy. It makes perfect sense to be able to do what I want to do and I think it's crappy that it's not allowed.
Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)
There is:
Notice that you don't have a pointer to a function, you have a pointer to the object, which is the key, since the object itself knows what kind it is, and the compiler doesn't as you're lying to the compiler about what class vpptr points to.Code:class viewPort { //... stuff ... virtual void aPlot(int, int, unsigned long); }; class vSpec : public viewPort { //... stuff ... void aPlot(int, int, unsigned long); }; viewPort * vpptr = new vSpec(); vpptr->aPlot(2,3,4L);
Again, my suggestion is to read the chapters about polymorphism.
But vSpec needs the proper plot function too. I just wanted to be able to extend the repertoire of plot methods in the derived class.
Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)
It has it. (Assuming by "proper plot function" you mean it's own.)
Another solution:
When you declare a function in a class (f(x)) it's really (f(self, x)). where self is a pointer in memory of the data to act upon.Code:class viewPort { . . . public: static void plot (viewPort* self, int x, int y, int col); void (*plotH) (viewPort* self, int x, int y, int col); }; . . . viewPort::viewPort (int width, int height, HWND hwnd) { . . . plotH = &plot; . . . }
In simple terms 'static' say's leave as is, unfortunately if you want to act on data upon the memory location, you'll need to supply it yourself. I think there is also another way but I don't remember. There is a strategy paradigm, I know little about though.
When calling within the viewPort class
When calling from somewhere elseCode:void viewPort::somefunction(){ plotH(this, x, y, col); }
Code:int main(){ viewPort view; viewPort *pview; pview = &view; // initialize and stuff view.plotH(&view, x, y, col); // or if you have a pointer pview->plotH(pview, x, y, col); // ... }
Last edited by Benzakhar; 09-02-2008 at 08:24 PM.
The MORE I read the this, the MORE I think my suggestion is the right one - don't use function pointers, use virtual functions in a class. Not only does it simplify the syntax of the whole lot, but it will "magically work" without much effort, instead of trying to make something that work that doesn't.
Of course, Benzakhar's solution will work - you can pass a pointer to the object, and then call a static function. But this is basically just "doing your own virtual functions" - you are reinventing the wheel, except your wheel is a octagon in approximation of a circle, so your ride will be a bit bumpy.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I agree with mats - polymorphism should do fine. Either static or dynamic.
Another "way" around your problem is also templates, because it can be any type, you can pass "any" member function pointer. But I don't think your problem requires this. It can be a more advanced solution.
