@cgracey said:
You can actually pass method pointers anywhere within an application and use them. They hold (and point to) complete contextual data. They needn't be run at the same level they were made at. You can get a pointer to any method in your current object and any PUB method in any child object. Once you have that method pointer established, you can pass it and use it anywhere in your application's scope. It is, after all, just a long.
You're right, Chip. But one cannot have the same behavior as the SEND method pointer does, even though one would establish it with a method which expects only one parameter. The signature of method, assigned to SEND and to my own method pointer, will be the same but one cannot pass a parameter list to my own method pointer as with SEND is possible.
It would be great if the compiler could be figure this out and could flag such method pointer that it would have the same behavior as SEND. I don't know if there is a bit remaining on the method pointer to do that.
@Cluso99 said:
So now I think I can do this
send(ser.fstr1(string("Port-params %8x\r\n"), addr2))
But it doesn't allow this
send(ser.fstr1(string("Port-params %8x\r\n"), addr2))
send(ser1.fstr1(string("Port-params %8x\r\n"), addr2))
because you would need to add an intervening line to redirect send, and then another line after to return to the original. Correct?
The compiler will not allow this as the fstr1 method does not return a value which could be use by send. Also if you would return the formatted string it would not work as expected as the return value would be a pointer to the string. And that's only a long which would be passed to the assigned method, in this case the tx method of the driver, and you would see something weird but not the string.
Hence, I used the other way. The send call was used in a generic formatting object where I used the extracted interface of the full-duplex driver and used the send call at any place where a single character should be sent. So, you can use this interface as usual for any driver to send formatted strings to this driver redirected via the SEND method pointer. This has the advantage that both (the driver and the generic formatting interface) are decoupled.
On the send call a string can be only hard coded by using quotes. There is no way to use a pointer to a string as the string function does return as this is only a long and this cannot be differentiated from a value provided as byte, word or long.
Functions called by SEND do not need to return a value. That is, send(myobj.myfunc(x)) is fine even if myobj.myfunc does not return any value. The compiler will still insert the call, but won't try to output any value based on the return (since there isn't any). Inside myobj.myfunc the SEND value is stil valid, so the method may explicitly use it to output data. That's how my format object work.
@ersmith said:
Functions called by SEND do not need to return a value. That is, send(myobj.myfunc(x)) is fine even if myobj.myfunc does not return any value. The compiler will still insert the call, but won't try to output any value based on the return (since there isn't any). Inside myobj.myfunc the SEND value is stil valid, so the method may explicitly use it to output data. That's how my format object work.
Thanks for clarification, Eric. You're right, one can use any method as parameter with send even if it does not return a value.
@cgracey said:
You can actually pass method pointers anywhere within an application and use them. They hold (and point to) complete contextual data. They needn't be run at the same level they were made at. You can get a pointer to any method in your current object and any PUB method in any child object. Once you have that method pointer established, you can pass it and use it anywhere in your application's scope. It is, after all, just a long.
You're right, Chip. But one cannot have the same behavior as the SEND method pointer does, even though one would establish it with a method which expects only one parameter. The signature of method, assigned to SEND and to my own method pointer, will be the same but one cannot pass a parameter list to my own method pointer as with SEND is possible.
It would be great if the compiler could be figure this out and could flag such method pointer that it would have the same behavior as SEND. I don't know if there is a bit remaining on the method pointer to do that.
Consider that SEND is conveyed to all called methods. I don't know how we would do this for any method, unless the compiler hid a SEND reassignment and restoration.
Comments
Do you use the latest version of FlexProp? I know there was an issue with that but that should be already fixed.
You're right, Chip. But one cannot have the same behavior as the SEND method pointer does, even though one would establish it with a method which expects only one parameter. The signature of method, assigned to SEND and to my own method pointer, will be the same but one cannot pass a parameter list to my own method pointer as with SEND is possible.
It would be great if the compiler could be figure this out and could flag such method pointer that it would have the same behavior as SEND. I don't know if there is a bit remaining on the method pointer to do that.
The compiler will not allow this as the fstr1 method does not return a value which could be use by send. Also if you would return the formatted string it would not work as expected as the return value would be a pointer to the string. And that's only a long which would be passed to the assigned method, in this case the tx method of the driver, and you would see something weird but not the string.
Hence, I used the other way. The send call was used in a generic formatting object where I used the extracted interface of the full-duplex driver and used the send call at any place where a single character should be sent. So, you can use this interface as usual for any driver to send formatted strings to this driver redirected via the SEND method pointer. This has the advantage that both (the driver and the generic formatting interface) are decoupled.
On the send call a string can be only hard coded by using quotes. There is no way to use a pointer to a string as the string function does return as this is only a long and this cannot be differentiated from a value provided as byte, word or long.
Functions called by SEND do not need to return a value. That is,
send(myobj.myfunc(x))is fine even ifmyobj.myfuncdoes not return any value. The compiler will still insert the call, but won't try to output any value based on the return (since there isn't any). Inside myobj.myfunc the SEND value is stil valid, so the method may explicitly use it to output data. That's how my format object work.OK, thanks
Thanks for clarification, Eric. You're right, one can use any method as parameter with send even if it does not return a value.
Consider that SEND is conveyed to all called methods. I don't know how we would do this for any method, unless the compiler hid a SEND reassignment and restoration.