-
assigned issue to
Fix vector assignment ambiguity on C++ side
The present interface is unclear in that vector assignment is, e.g.is it component-wise assignment or object assignment.
Comments (17)
-
reporter -
What do you mean?
GenericVector::operator= (const GenericVector& x)
? -
reporter @blechta Yes. In the code
Vector a, b; . . . a = b;
it's not clear if
b
is assigned toa
, or if the vector values ofb
are copied toa
. From Python, we havea[:] = b[:]
to be clear that the above copies values (component-wise).
-
I guess that depends on how you view Vector: as analogous to std::vector<double> (a=b would copy values) or analogous to std::shared_ptr<BackendVector> (a=b would copy pointer to backend object). How do you intend to fix the ambiguity?
-
One should not be able to change dimensions of
Function::_vector
(it could lead to strange bugs I guess). So from this POVGenericVector::operator[+-*/]=(any_type)
should be documented to mean pointwise assignment and test should be written.If we were enforcing consistency too strictly, we would extend this policy to
GenericTensor
s. -
reporter For a
std::vector
,a=b
would assign the object, not do element-wise assignment.The 'fix' is probably to deprecate
GenericVector::operator=
and have well documentedGenericVector::copy
(copy object) andGenericVector::assign
(assign values) functions. This would be similar to the NumPy terms. -
It does not matter how is a method named but what it does. We should test that backends raise on any strange assignment (either operator= or assign).
-
Speaking about preferring
assign
tooperator=
andcopy
method to usual copy constructor has one drawback. Since from well-know reasons it is every time preferable to implement assignment operator and copy constructor, you would end up writing all four of them for every implementation. -
reporter @blechta Of course it matters what something is called. It's paramount. Names should reflect as closely and clearly as possible what an operation does, and be chosen to minimise the likelihood of misuse.
-
reporter Copy constructor is probably fine. Assignment operator in base class can throw an error, or maybe made private.
-
Assignment operator in base class can throw an error, or maybe made private.
Agree. Sorry for ignorance, I needed to test it by myself. Then no objections.
-
Actually, if the sizes of
std::vector a,b
are the same,a=b
does do element-wise assignment. And in particular,a
does not reference the data ofb
afterwards, so after doinga=b
, modifying either should not affect the other (that would be very confusing).What @blechta referred to was that if either the copy constructor or operator= is defined, both should be. So it's best to hide both by making them private.
-
Note that when made private, they don't need to be implemented. Then the compiler will give an error if usage is attempted even in private context.
-
Actually, here's the C++11 way of doing it:
class X { // ... X& operator=(const X&) = delete; // Disallow copying X(const X&) = delete; };
-
reporter @martinal Nice.
-
- removed milestone
Removing milestone: 1.7 (automated comment)
-
reporter - changed milestone to 2017.2
- Log in to comment