Add explicit keyword to constructors
Resolves cppcheck warnings noExplicitConstructor, useInitializationList, and passedByValue.
~There's one warning I wasn't able to resolve.
NimBLEUUID(const ble_uuid_any_t& uuid);~
~If I make that constructor explicit then I get this compile error.~
Log
managed_components/esp-nimble-cpp/src/NimBLERemoteValueAttribute.h: In constructor 'NimBLERemoteValueAttribute::NimBLERemoteValueAttribute(const ble_uuid_any_t&, uint16_t)':
managed_components/esp-nimble-cpp/src/NimBLERemoteValueAttribute.h:189:107: error: no matching function for call to 'NimBLEAttribute::NimBLEAttribute(const ble_uuid_any_t&, uint16_t&)'
189 | NimBLERemoteValueAttribute(const ble_uuid_any_t& uuid, uint16_t handle) : NimBLEAttribute(uuid, handle) {}
| ^
In file included from managed_components/esp-nimble-cpp/src/NimBLERemoteService.h:24,
from managed_components/esp-nimble-cpp/src/NimBLEDevice.h:261:
managed_components/esp-nimble-cpp/src/NimBLEAttribute.h:48:5: note: candidate: 'NimBLEAttribute::NimBLEAttribute(const NimBLEUUID&, uint16_t)'
48 | NimBLEAttribute(const NimBLEUUID& uuid, uint16_t handle) : m_uuid{uuid}, m_handle{handle} {}
| ^~~~~~~~~~~~~~~
managed_components/esp-nimble-cpp/src/NimBLEAttribute.h:48:39: note: no known conversion for argument 1 from 'const ble_uuid_any_t' to 'const NimBLEUUID&'
48 | NimBLEAttribute(const NimBLEUUID& uuid, uint16_t handle) : m_uuid{uuid}, m_handle{handle} {}
| ~~~~~~~~~~~~~~~~~~^~~~
managed_components/esp-nimble-cpp/src/NimBLEAttribute.h:29:7: note: candidate: 'constexpr NimBLEAttribute::NimBLEAttribute(const NimBLEAttribute&)'
29 | class NimBLEAttribute {
Also NimBLEHIDDevice needs to be updated to be compliant with this change.
For example: m_deviceInfoSvc = server->createService(deviceInfoSvcUuid);
Do you think it's better to just create a new constructor which can take a uint16_t, or change such instances like this?
m_deviceInfoSvc = server->createService(NimBLEUUID(deviceInfoSvcUuid));
I've gone with the latter (though I excluded the file from the commit for now), though adding the new constructor would probably make it easier to read NimBLEHIDDevice.
Edit: Or this
static constexpr uint16_t deviceInfoSvcUuid = 0x180a;
static const NimBLEUUID deviceInfoSvcUuid = NimBLEUUID((uint16_t)0x180a);
I think m_deviceInfoSvc = server->createService(NimBLEUUID(deviceInfoSvcUuid)); is probably fine here as it's an internally managed class so application code isn't affected, still quite readable as well.
Would this be considered a breaking change? Any applications making use of these implicit conversions will fail to compile, though the changes should be easy to make.
I'll make a separate PR for NimBLEHIDDevice.
It might be, depending on the application.
I would suggest adding the HID changes to this PR so we can test the builds at least. Maybe add some more build tests to find where it may fail so it can be documented?