Steven Schveighoffer wrote:
I guess I'm not really sure what the "acquire" method does. I saw you
mention it in another post, but with no explanation as to what it actually
does, just that it was needed. I'm sure I'm not getting what should be
obvious, but if you could enlighten, I would appreciate it :)
Say you have an object obj that has a Matrix property and you have a
Matrix object handy. The Matrix is rather resource intensive so you'd
rather not copy it unwittingly. Conventionally, if you say:
Matrix m;
... fill matrix ...
obj.matrix = m;
then m is copied into obj.matrix (there is the by-value call to set
property). Now it's possible to arrange things such that m is
destructively copied, but as the auto_ptr disaster has shown, it's not
that intuitive to make assignment destroy the right hand side.
So we'd need a distinct method:
obj.matrix.acquire(m);
That method takes the matrix by reference, sucks its life out of it, and
leaves an empty shell behind. Pretty much like in your average horror movie.
Having the two functions seems like a reasonable baggage compromise, if you
want to control the get and set methods of a property and pass that control
to an underlying function, you need at least that. If we start generalizing
it to anything, then it starts looking like struct interfaces would be more
suitable. For example, you could allow setting an int property using both
an int and a string, do you want to pass both setters to a function? I
think limiting it to just a set and a get function should be sufficient.
With only get and set I can't implement a nothrow swap, which kinda
bends me out of shape.
Andrei
