Opened 13 years ago

Closed 13 years ago

#339 closed defect (fixed)

Vector: indirect self-assignment)

Reported by: Peter Owned by: Peter
Priority: major Milestone: yat 0.4
Component: utility Version: trunk
Keywords: Cc:

Description

How should vector behave in assignment in which rhs is a view into lhs.

An example that currently does not work:

Vector vec(10, 2.3);
VectorView view(vec);
vec = view
cout << vec << "\n";
VectorView subview(vec, 1, 5);
vec = subview
cout << vec << "\n";

Should we allow this kind of assignment, or should we throw an exception, or simply ignore it? I'm not sure I understand how to detect this, especially not in second case when the vectors are different.

Change History (5)

comment:1 Changed 13 years ago by Jari Häkkinen

Doesn't views become invalid when operator= is used. The LHS vector is always changed. In this is the case I see no problem above.

So, with the current operator= specification the assignment should simply be allowed.

However, there is no protection against self-assignment of any kind, memory is deleted before it is copied, so a vec=vec; is disastrous in the current code. Also, vec=view; is a potential disaster. I would like to say the operator= implementation is seriously flawed.

comment:2 Changed 13 years ago by Peter

Yes, I agree. That is what this ticket is about.

That is what I found when I polished up the docs.

I interpret you as we should allow this kind of assignment, which implies

  • protect against self-assignment
  • protect against indirect self assignment (vec=view in description)
  • when assigning to a subview we need to create temporary gsl_vector, which we can use to do the copying.

What happens to the rhs? I think we can leave that undefined.

comment:3 Changed 13 years ago by Peter

Status: newassigned

You are right. Assignment invalidates all views into LHS.

comment:4 in reply to:  2 Changed 13 years ago by Jari Häkkinen

Replying to peter:

I interpret you as we should allow this kind of assignment, which implies

  • protect against self-assignment
  • protect against indirect self assignment (vec=view in description)
  • when assigning to a subview we need to create temporary gsl_vector, which we can use to do the copying.

What happens to the rhs? I think we can leave that undefined.

RHS? There is no problems if it is a vector ... nothing happens (not even for self assignment). In the case of a view there is no problem if it is not a view to the LHS vector. The problematic case is when a view is a view into the LHS vector, but this is easily resolved since the view becomes invalid directly after assignment. There is nothing undefined here.

Trying to outline how to protecting against indirect self assignment. This is simply to compare pointers and ranges (we are working with continuous memory space here). If done properly there is no need to always copy the gsl_vector for the views. I.e., a copy is only needed for the indirect self assignment case not always for a view in RHS. Remember the vector to copy is the RHS.

comment:5 Changed 13 years ago by Peter

Resolution: fixed
Status: assignedclosed

fixed in [1135]

Note: See TracTickets for help on using tickets.