Fix Coverity hits for covariance, correlation and cosine distances #3017
Conversation
|
/intelci: run |
|
/intelci: run |
| @@ -126,8 +126,9 @@ class DAAL_EXPORT InputIface : public daal::algorithms::Input | |||
| { | |||
| public: | |||
| InputIface(size_t nElements) : daal::algorithms::Input(nElements) {} | |||
| InputIface(const InputIface & other) : daal::algorithms::Input(other) {} | |||
| virtual size_t getNumberOfFeatures() const = 0; | |||
| InputIface(const InputIface & other) = default; | |||
There was a problem hiding this comment.
This sort of thing (adding definitions in headers that get compiled for different instruction sets) was causing 'illegal intruction' errors in the CI:
#3012
There was a problem hiding this comment.
Here, I only did this in places where constructor was already defined in header
There was a problem hiding this comment.
It looks like this method (L130) wasn't there before:
InputIface & operator=(const InputIface & other) = default;There was a problem hiding this comment.
Yeah, but copy-constructor was already defined in header, so I think defining copy-assignment operator here wouldn't change anything
There was a problem hiding this comment.
Perhaps @Vika-F could provide some perspective here.
|
/intelci: rerun |
| @@ -380,7 +388,8 @@ class DAAL_EXPORT DistributedInput<step1Local> : public Input | |||
| { | |||
| public: | |||
| DistributedInput() : Input() {} | |||
| DistributedInput(const DistributedInput & other) : Input(other) {} | |||
| DistributedInput(const DistributedInput & other) = default; | |||
| DistributedInput & operator=(const DistributedInput & other) = default; | |||
There was a problem hiding this comment.
As for this class I can't find a respective cpp with implementation, so I'm not sure if we can move the implementation of this functions from here. I don't understand the purpose of DistributedInput maybe it should removed in the future
|
/intelci: run |
Description
Fix the violation of "Rule of three" for covariance, correlation and cosine distances algorithms
PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.
You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).
Checklist to comply with before moving PR from draft:
PR completeness and readability
Testing
Performance