C / C++ / MFC

Re: One more error using function pointers - void value not ignored as it ought to be

9-Oct-16 21:42

Sorry to butt in but your problem has nothing to do with classes or inheriting it's just code syntax that would not work anywhere.

Lets review function pointers ..
1.) you can set then to a function using the "&" symbol
2.) you can transfer the value to another function pointer that matches.

Can I suggest you first try and write just two function pointers in normal C++ and try to set them ... here let me write the code for you

 void someFunc (char* text){
     // .... some code in here
}

// Here are our two function pointers
void(*FunctionPointer_A)(char *);
void(*FunctionPointer_B)(char *);

// You can set either of them to the function using the & symbol .. item 1 use of function pointers
FunctionPointer_A = &someFunc;
FunctionPointer_B = &someFunc;

// Or you can set one and copy the other which is item 1 then item 2 use of function pointers
FunctionPointer_A = &someFunc;
FunctionPointer_B = FunctionPointer_A ;

I think this later is what you are attempting to do and if you copy the code in you should find it happily compiles.

Forgetting the class prefix this what you typed is nonsense .. it doesn't meet either of the item 1 or 2 formats

FunctionPointer_B = Process_INHERITANCE_A( Text);

After Richards suggestion you at least seem to get the function pointer setting

FunctionPointer_B = &INHERITANCE_A::Process_INHERITANCE_A;

That I can at least I can understand and is ever so close but now we come details of a class.

Any class function has a hidden self pointer pushed down on the function call. You don't see it the C++
compiler hides the syntax from you. So basically your function pointer doesnt equal the actual function
of a class function .. that is what the compiler is complaining about.

Your function pointer B needs to reflect its a class member function pointer .. not a function pointer to a static code
redefine it to

void(INHERITANCE_A::*FunctionPointer_B)(char *);

You may also need to typedef this if you want to carry the function as a forward declaration

All that is really happening is the function pointer knows to push the class self pointer down before it calls but from
your perspective it makes the compiler see the two as the same type.

There are better ways to do the function pointer assignment for classes, the magic term to do a search for is
memberfunctionpointer. Because you are trying to make a function pointer to a member function in a class.
Try:Member Function Pointers and the Fastest Possible C++ Delegates[^]

In vino veritas

modified 10-Oct-16 4:57am.

Richard MacCutchan9-Oct-16 21:49

Re: One more error using function pointers - void value not ignored as it ought to be

9-Oct-16 21:49

A nice clear explanation. Thumbs Up | :thumbsup:

leon de boer9-Oct-16 23:23

Re: One more error using function pointers - void value not ignored as it ought to be

9-Oct-16 23:23

I am still confused what he is trying to do. Why does he need the function pointer internal to the
class he can call any function from the inherited interfaces directly. You usually only do member
function calls from a block of code outside the class.

In vino veritas

Richard MacCutchan9-Oct-16 23:25

Re: One more error using function pointers - void value not ignored as it ought to be

9-Oct-16 23:25

Yes, I can't quite figure out what is (supposed to be) going on, and none of the code snippets make it any clearer.

Vaclav_10-Oct-16 4:17

Re: One more error using function pointers - void value not ignored as it ought to be

10-Oct-16 4:17

Thanks, really helpful to make me understand how function pointer works.
The whole exercise is to be able to call from one class to another in the hierarchy.
What I am doing is recoding an app which was written without classes, I call it "flat" for lack of other words.
It is basically relations between embedded processor hardware devices - USB , USB host, UART ( print) , LCD and video camera ( USB device).
I am trying to use compound inheritance with top class managing the process of getting video data to the LCD.
It is interrupt driven and I think that is where I went wrong - I need to rebuild the inheritance relations to have the interrupt driven class as "mother ship".
I am pretty much done , the last piece is to actually process the video buffer.
That is where the function pointers are used.

Thanks again, you guys are very helpful and I appreciate that,

leon de boer10-Oct-16 4:32

Re: One more error using function pointers - void value not ignored as it ought to be

10-Oct-16 4:32

So the function call is from outside the class in the interrupt?

That will be fun trying to make sure the class in a stable running state not starting or closing, before you start passing interrupts into it. You will get a nice big crash if you pass an interrupt into the class and it isn't stable Smile | :)

In vino veritas

modified 10-Oct-16 10:42am.

Vaclav_10-Oct-16 13:20

Re: One more error using function pointers - void value not ignored as it ought to be

10-Oct-16 13:20

The original code has ISR collecting the (video ) data and when it detects end of frame another function does the actual video output to the LCD.
I put the ISR code in one class and the output to LCD in another class.
Now both classes inherited from Print class so I can do code debugging etc.
There are other hardware inheritances - USB , SPI but that is all working.

That is how the compound inheritance came to be, and that is basically working.

The issue is the link between the ISR and LCD class.
I was hoping for another upper layer of class to be the controlling class, but that seems to be convoluted way to do it.
I think I have a better grasp on using function pointers and will try to just call from one class to another using pointers.

BTW the hardware interrupt is continuous and there are some checks in the actual interrupt handler and ISR functions making sure it is running and getting correct data / USB packages.

Thanks to the group I think I got the basics, now it is just a matter of organizing the puzzle.

leon de boer10-Oct-16 17:02

Re: One more error using function pointers - void value not ignored as it ought to be

10-Oct-16 17:02

What you have just said above is what makes what you are doing weird to us.

There is no need to inherit a print class just to print, you just hold a print
class instance in your class data and initialize it and you can print to it at
any time you need.

You don't inherit things just so you can use them. You only inherit things you
need to change the behaviour. Your class interface is just bloating up and
you gain exactly zero as you could already print what you need using the
original class.

So let me ask the specific question does your class change the print interface
it inherits in any way? If you answer no then you don't need to inherit it just
create an instance of the class in your class.

In vino veritas

Vaclav_11-Oct-16 7:01

Re: One more error using function pointers - void value not ignored as it ought to be

11-Oct-16 7:01

The idea was - lazy man way .
As written originally - the LCD class was derived / inherited from class Print.
All usage of class Print was just calling the Print methods via inheritance, directly.
To do what you suggest , which make perfect sense, I would have to change my other classes using Print methods to use the Print object. That is why I though multiple inheritance would work. It does , but things get tangled.

And yes, I know how to do "find and replace ".

I also have these "chain" dependencies and not sure how to tackle that using your method.
I guess going from "flat" implantation to OOP is not that easy, but I hope I have Lerner few things in process.

Would using "friend" class be of any advantage? Not that I need another headache.

And no, my usage of inheritance does not change anything in class itself , they all basically just change / modify the data for their usage.

leon de boer11-Oct-16 17:26

Re: One more error using function pointers - void value not ignored as it ought to be

11-Oct-16 17:26

You said ... "To do what you suggest , which make perfect sense, I would have to change my other classes using Print methods to use the Print object."

No you don't all you need to do is create a printer class at initialization, lets say you have a private variable printer class called "ThePrinter". All it means is at the moment you are calling the inherited methods of the printer class directly so xyz_func(); so instead of that it would become ThePrinter.xyz_Func(); Really from a code point it's that simple a small change in the constructor and the name of the held printer infront of the printer class methods you are directly calling.

Besides making your interface a hell of a lot smaller and removing bloating code and data in your class it also allows you to do things you can't do like change the printer device on the fly or pass the printer class to another object or a block of code. If you want to share the printer, so two different classes can write to the exact same printer (which may be likely in your case), you get one class to make the printer and then simply make a function on that class so the other classes can get a pointer to the printer. So the class that has the printer does this via a function GetMyPrinter

class IHavePrinter{
    public:
    PrinterClass* GetMyPrinter(void); // Return the created printer is a public function
    private:
    PrinterClass ThePrinter;   // The actual created printer in this classes constructor
}

IHavePrinter:: PrinterClass* GetMyPrinter(void){
    return(&ThePrinter);       // Return pointer to the created printer
}

That is the point of keeping classes detached so you can do things you can't possibly do if you bind them into your object inheritance and you stop the vicious cross connection you are getting. I think most of your dependency issues is actually cause by your inheritance scheme and wouldn't exist if you did it properly.

You could just have exposed the printer object as a public but the few lines to pass it on a function means that later on if you want to track who is using the printer or know if it's in use you can modify that function to track that etc. So a bit of forward planning built into the concept and trying to keep the classes as detached as possible not accessing each others fields.

In vino veritas

modified 11-Oct-16 23:43pm.

Vaclav_12-Oct-16 14:42

Re: One more error using function pointers - void value not ignored as it ought to be

12-Oct-16 14:42

Thanks, so in my simple words - instead of using multiple inheritance in downstream fashion doing it this way is sort of in reverse - the printer class goes first.
Your are very helpful and much appreciated.
Thanks.
Cheers Vaclav

leon de boer12-Oct-16 17:09

More basic C++ questions - may I ask?

12-Oct-16 17:09

Yes we are putting composition over inheritance, so our classes are trying to achieve multiple
and flexible behaviour (reusing as much code as possible) rather than inheritance from a base
or parent class.

I would also add there is one final thing you will be able to do if you go that path which you
can't possibly do with your current scheme, which is to thread the classes or at least the one
that had the old ISR code to help its response and speed.

In vino veritas

Vaclav_8-Oct-16 15:24

8-Oct-16 15:24

I am still not too comfortable with passing variables to
constructor, but eventually I'll get over it.

But this got me stumped - never heard of having const used this way. Why?
So how do you read this -X(x) with relation to following function double x()?

Please if this is too basic for you just let someone else answer, OK?
I am asking for help and have no intent to waste your time on trivia.
Thanks

class Point2d{
public:
Point2d() {}
Point2d(double x, double y)
: X(x), Y(y) {}

double x() const { return X; }
double y() const { return Y; }

/**
* Returns the norm of this vector.
* <a href="http://www.codeproject.com/Members/return">@return</a> the norm
*/
double norm() const {
return sqrt( X * X + Y * Y );
}

void setCoords(double x, double y) {
X = x; Y = y;
}

Midi_Mick8-Oct-16 15:52

Midi_Mick

8-Oct-16 15:52

Using const that way in the declaration of the method tells the compiler that the method is able to be called on constant instances of that object. It indicates that the object is not altered in any way by calling that method. Examples using the class defined above:

const Point2d p1(2,3);
Point2d p2(4,5);

p1.setCoords(3,2);   // Compiler error. setCoords not declared as const method
p2.setCoords(5,4);   // OK

double n = p1.norm(); // OK - norm declared as const method

Cheers,

Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.

Richard MacCutchan8-Oct-16 20:37

8-Oct-16 20:37

It's all in the documentation: https://msdn.microsoft.com/en-us/library/07x6b05d.aspx[^].

modified 10-Oct-16 5:02am.

Vaclav_9-Oct-16 6:20

9-Oct-16 6:20

The link is broken.
Thanks anyway

Richard MacCutchan9-Oct-16 6:27

9-Oct-16 6:27

~~It was working this morning, because I read the content to see that it answered the question. Most likely a problem at Microsoft's end; keep trying. Or just use Google to find an alternate page.~~CodeProject bug, link now fixed.

modified 10-Oct-16 5:02am.

Graham Breach9-Oct-16 21:46

Graham Breach

9-Oct-16 21:46

There's a colon missing between the "https" and "//" in your link - but it's there in the link text. Maybe this a CodeProject bug?

Richard MacCutchan9-Oct-16 23:00

9-Oct-16 23:00

Thanks, there is a message in Bugs & Suggestions about this, but it is supposed to be fixed now. I will edit my response.

Ratul Thakur10-Oct-16 21:42

Ratul Thakur

10-Oct-16 21:42

*i am also new to C++*
i'm not able to figure out where are X and Y defined
i mean the capital ones.