[Ovmsdev] Duktape Persistent Function References
dexter at expeedo.de
Fri Sep 25 21:10:20 HKT 2020
the issue is, there are ambiguous overloads of these methods in their
classes, and the compiler doesn't know which one to pick.
I prefer to keep my command stub names distinguished from their
implementation counterparts, but apparently that doesn't apply to all of
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.
Am 25.09.20 um 08:07 schrieb Mark Webb-Johnson:
> 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:
> 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
> In constructor
> error: no matching function for call to
> 'OvmsCommand::RegisterCommand(const char , const char ,
> <unresolved overloaded function type>, const char , int, int)'
> CXX build/vehicle_mgev/src/vehicle_mgev.o
> .../components/vehicle_mgev/src/vehicle_mgev.cpp: In constructor
> .../components/vehicle_mgev/src/vehicle_mgev.cpp:143:5: error: no
> matching function for call to
> 'OvmsCommandApp::RegisterCommand(const char , const char ,
> <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:
>> 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
>> 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.
>> 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>
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev