esp-nimble-cpp icon indicating copy to clipboard operation
esp-nimble-cpp copied to clipboard

Add explicit keyword to constructors

Open thekurtovic opened this issue 11 months ago • 4 comments

Resolves cppcheck warnings noExplicitConstructor, useInitializationList, and passedByValue.

thekurtovic avatar Jan 04 '25 23:01 thekurtovic

~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);

thekurtovic avatar Jan 04 '25 23:01 thekurtovic

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.

h2zero avatar Jan 06 '25 00:01 h2zero

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.

thekurtovic avatar Jan 06 '25 00:01 thekurtovic

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?

h2zero avatar Jan 06 '25 00:01 h2zero