[Ovmsdev] Duktape Persistent Function References

[Michael Balzer]

I understood I should add the change to std::function in ovms_command
only to the for-v3.3 branch, so Chris didn't take that into account yet.

Regards,
Michael


Am 25.09.20 um 15:22 schrieb Mark Webb-Johnson:
> Wow. That would have taken me hours to work out. Thanks.
>
> Any idea why it compiled in master, but not in for-v3.3?
>
> Regards, Mark.
>
>> On 25 Sep 2020, at 9:10 PM, Michael Balzer <dexter at expeedo.de
>> <mailto:dexter at expeedo.de>> wrote:
>>
>> Mark,
>>
>> the issue is, there are ambiguous overloads of these methods in their
>> classes, and the compiler doesn't know which one to pick.
>>
>> -
>> https://stackoverflow.com/questions/10111042/wrap-overloaded-function-via-stdfunction
>> -
>> https://stackoverflow.com/questions/30393285/stdfunction-fails-to-distinguish-overloaded-functions
>>
>> I prefer to keep my command stub names distinguished from their
>> implementation counterparts, but apparently that doesn't apply to all
>> of us ;-)
>>
>> Coming C++ versions may be smart enough to deduce the method to pick
>> from the expected signature.
>>
>> For now, the compiler needs a hint here. I've added two preprocessor
>> macros to make these hints readable.
>>
>> Regards,
>> Michael
>>
>>
>> Am 25.09.20 um 08:07 schrieb Mark Webb-Johnson:
>>> @Michael,
>>>
>>> I’ve tried merging this (along with all the other recent changes in
>>> master) into the for-v3.3 branch, but am now getting compilation
>>> errors. The two files with issues are:
>>>
>>>     components/retools_testerpresent/src/retools_testerpresent.cpp
>>>     components/vehicle_mgev/src/vehicle_mgev.cpp
>>>
>>>
>>> Both in the RegisterCommand function call with the static class
>>> member function as a parameter. Not sure if that new way is used
>>> elsewhere?
>>>
>>> Example compiler output is:
>>>
>>>     CXX build/retools_testerpresent/src/retools_testerpresent.o
>>>     .../components/retools_testerpresent/src/retools_testerpresent.cpp:
>>>     In constructor
>>>     'OvmsReToolsTesterPresentInit::OvmsReToolsTesterPresentInit()':
>>>     .../components/retools_testerpresent/src/retools_testerpresent.cpp:140:5:
>>>     error: no matching function for call to
>>>     'OvmsCommand::RegisterCommand(const char [6], const char [48],
>>>     <unresolved overloaded function type>, const char [23], int, int)'
>>>          );
>>>          ^
>>>
>>>     CXX build/vehicle_mgev/src/vehicle_mgev.o
>>>     .../components/vehicle_mgev/src/vehicle_mgev.cpp: In constructor
>>>     'OvmsVehicleMgEv::OvmsVehicleMgEv()':
>>>     .../components/vehicle_mgev/src/vehicle_mgev.cpp:143:5: error:
>>>     no matching function for call to
>>>     'OvmsCommandApp::RegisterCommand(const char [8], const char
>>>     [15], <unresolved overloaded function type>)'
>>>          );
>>>          ^mand(const char* name, const char* title,
>>>                       ^
>>>
>>>
>>> I tried for a while, but can’t see what is wrong. Perhaps some
>>> missing header file? Anyway, I’ve committed the merge of master into
>>> for-v3.3 (even though it doesn’t compile) and just commented out
>>> those registrations in my local copy.
>>>
>>> Can you help?
>>>
>>> Thanks, Mark.
>>>
>>>> On 12 Sep 2020, at 5:12 AM, Michael Balzer <dexter at expeedo.de
>>>> <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>> Mark,
>>>>
>>>> Am 11.09.20 um 18:11 schrieb Michael Balzer:
>>>>>> I agree it is not necessary; my suggestion is purely to clean it up
>>>>>> and enhance functionality. The problem at the moment is that
>>>>>> OvmsCommand execute callbacks can only be to function callbacks (not
>>>>>> objects). It doesn’t even use the c++ bind function callback
>>>>>> mechanism (like notification, etc, for example). It is what it is,
>>>>>> and changing now is very hard.
>>>>>
>>>>> That slipped my attention, but upgrading OvmsCommand to accept any
>>>>> function type should be simply changing m_execute and m_validate to
>>>>> std::function, or do I miss something?
>>>>
>>>> Just did this locally, works perfectly. Shall I push the change or have
>>>> you begun working on ovms_command?
>>>>
>>>> If so, it's really just exchanging the function signatures for
>>>> these types:
>>>>
>>>> typedef std::function<void(int, OvmsWriter*, OvmsCommand*, int, const
>>>> char* const*)> OvmsCommandExecuteCallback_t;
>>>> typedef std::function<int(OvmsWriter*, OvmsCommand*, int, const char*
>>>> const*, bool)> OvmsCommandValidateCallback_t;
>>>>
>>>> Patch attached.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> -- 
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>
>>>> <ovmscommand.patch>_______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200925/b2fcd9b7/attachment-0002.htm>