Is DiscoveryInformation intentionally not copyable?

Programming Questions
1

I have a question about the C++ API of :cvb:.
I am using the latest version (14.00.010) of :cvb: at this time.

The class Cvb::DiscoveryInformation defines a move constructor and declares a defaulted move assignment operator. (However the move constructor of Cvb::DiscoveryInformation behaves like a copy constructor.)

Because of that, instances of Cvb::DiscoveryInformation cannot be copied.
From cppreference.com:

The implicitly-declared copy constructor for class T is defined as deleted if T declares a move constructor or move assignment operator.

Why should instances of Cvb::DiscoveryInformation class not be copied?
It is just a std::shared_ptr and an int.
If this is the intended behavior, why not just use a std::unique_ptr instead of std::shared_ptr as the member?

Why I want to copy Cvb::DiscoveryInformation:
I would like to store instances of Cvb::DiscoveryInformation, wrapped in std::any, in my own struct because our application needs to deal with other APIs too. I then later open a camera from the data in this struct. The struct should manage the lifetime of the Cvb::DiscoveryInformation instance(s) and therefore the lifetime of the list, that they point to.
Right now, I’m doing the discovery again for each camera that should be opened, however, even one discovery takes several seconds. I want to avoid doing multiple discoveries.

The class any describes a type-safe container for single values of any copy constructible type.

Is it safe to modify the C++ header files myself? (Removing move constructor & assignment operator or declaring defaulted copy constructor(s) and copy assignment operator(s))
If yes, can this be changed in a future release?

2

Hi @t.weigt ,
Thank you for using :cvb: .
Please be aware, that the Cvb::DiscoveryInformation class should not be confused with the return value of the containing AccessToken member function.

The Cvb::DiscoveryInformation class holds more than you mentionned, and is fairly depending on the runtime state it is living in. For example: There is an Index() function, that returns the index in a bigger list of discovered devices. Also The information may contain properties that have been modified through SetParameter. The overall intention is not to save the state of the DiscoveryInformation. That is why we chose that class design.

What i think you want to achieve is to open devices, that may return with exactly the same information from another discovery (which makes the re-discover redundant). Actually, this was the intention in the design of the String inside the AccessToken(). For your purpose: Save the string and open a device with it.
Of course, the interface is not persistent over CVB versions, as the AccessToken is enriched with newer functionality, but it can be renewed after time programmatically.

The access token is the entity you open your device with. But - as mentionned - be careful with the portability.

Generally, it is not recommened to edit the public header.