Good catch, can't say I've used that method much. Any reason not to just return a pointer/reference there instead of copying?

Well I did not design the API! ;)

I added NimBLEAdvertisedDevice *getDevice(const NimBLEAddress &address) in PR #46, and this works correctly without the copy constructor. However, I think it is not correct to return non-const pointers internal structures that should not be modified by the program. But non-const pointers are returned everywhere in this library! If we make them const, as suggested in PR #42, the user program should update all pointer variables to be const also, so this is not without impact.

If we return a reference we should come up with a solution to a getDevice() out-of-bounds. Now a nullptr is returned, then some kind of empty device should be returned.

Speaking of returning references, I think it would be cool to return references everywhere instead of returning pointers. But then we should introduce also 'empty objects' for (intermediate) non-existent services or characteristics. Also some kind of 'check breadcrumb trail' should be introduced in each leaf of the service.characteristic.descriptor tree, for the user to check, if the retrieval of a value fails, until what level the path is valid. This heavily changes the API!

I did some additional tests and I think the copy constructor is not necessary. Closing for now.

Yes ideally a const reference should be returned wherever internal structures are returned but that's a pretty big ask. I don't mind things as they are so much since it would be the API user that messes up the data if they change things, that;s on them 😃. The only other alternative is to return copies of the data, which I don't like, but is necessary sometimes.