Fix vector assignment ambiguity on C++ side

[Prof Garth Wells]

The present interface is unclear in that vector assignment is, e.g.is it component-wise assignment or object assignment.

[Jan Blechta]

What do you mean? GenericVector::operator= (const GenericVector& x)?

[Prof Garth Wells]

@blechta Yes. In the code

Vector a, b;
.
.
.
a = b;

it's not clear if b is assigned to a, or if the vector values of b are copied to a. From Python, we have

a[:] = b[:]

to be clear that the above copies values (component-wise).

[Martin Sandve Alnæs]

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?

[Jan Blechta]

One should not be able to change dimensions of Function::_vector (it could lead to strange bugs I guess). So from this POV GenericVector::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 GenericTensors.

[Prof Garth Wells]

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 documented GenericVector::copy (copy object) and GenericVector::assign (assign values) functions. This would be similar to the NumPy terms.

[Jan Blechta]

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).

[Jan Blechta]

Speaking about preferring assign to operator= and copy 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.

[Prof Garth Wells]

@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.

[Prof Garth Wells]

Copy constructor is probably fine. Assignment operator in base class can throw an error, or maybe made private.

[Jan Blechta]

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.

[Martin Sandve Alnæs]

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 of b afterwards, so after doing a=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.

[Martin Sandve Alnæs]

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.

[Martin Sandve Alnæs]

Actually, here's the C++11 way of doing it:

    class X {
        // ...
        X& operator=(const X&) = delete;    // Disallow copying
        X(const X&) = delete;
    };

from http://www.stroustrup.com/C++11FAQ.html#default

[Prof Garth Wells]

@martinal Nice.

[Anders Logg (Chalmers)]

Removing milestone: 1.7 (automated comment)