www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to modify an element in a range/collection using its member

reply Jens Mueller <jens.k.mueller gmx.de> writes:
Hi,

in Phobos opIndex returns a copy due to the reasons outlined in TDPL p.
378 (hiding the storage). Even though I find the argumentation
convincing and opIndexAssign/opIndexOpAssign usually makes the design
sound I ran into surprises when using member functions.
I use the Zip the range which has the same behavior, i.e. return a copy.
Consider a random-access range/container R of say 10 points.

auto c = R!Point(10);

If Point has member functions you naturally write buggy code as I did
(operating on a temporary Point).
c[2].changePointSomehow();

The work around is
auto tmp = c[2];
tmp.changePointSomehow();
c[2] = tmp;
which does not look good to me. Simply things should be simple.
swap won't work as changePointSomehow() does not return the modified
Point.

Should std.range.Zip be an exception and return by reference? Because it
actually does not store anything. I don't like this as Zip may perform
some optimization for indexing.

What is a good solution when using member functions on a
range's/container's element?

Note, the problem only applies when storing structs because classes
behave like references.

Jens
May 03 2012
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
I don't think that opIndexAssign/opIndexOpAssign were ever a good 
idea. Yeah, it works fine when all you are doing is x[i] = y, but 
that doesn't scale, as you have found out. It's short-sighted.

x[i] is an L-value for arrays, so it should be for everything 
else where it makes sense. Consistency is paramount.

I know C++ had the problem with std::map where x[i] would 
construct an entry when x[i] didn't exist, but that was due to a 
bad design decision. Indexing should never perform an insertion. 
Force users to use an 'insert' function to add elements and 
indexing should only work when the key is found (throw an 
exception otherwise). Again, it's a matter of consistency. 
Accessing x[10] of a 5-element array doesn't expand the array, so 
accessing x["foo"] of an empty map shouldn't expand the map.

Am I missing something here?
May 03 2012
prev sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Thursday, 3 May 2012 at 10:03:55 UTC, Jens Mueller wrote:
 What is a good solution when using member functions on a
 range's/container's element?

 Note, the problem only applies when storing structs because 
 classes
 behave like references.
I think in this case, it might make sense to store pointers to structs. So, auto c = R!(Point*)(10); OR alias Point* PointRef; auto c = R!PointRef(10); Let me know if there's something wrong with this approach.
May 03 2012
parent Jens Mueller <jens.k.mueller gmx.de> writes:
Chris Cain wrote:
 On Thursday, 3 May 2012 at 10:03:55 UTC, Jens Mueller wrote:
What is a good solution when using member functions on a
range's/container's element?

Note, the problem only applies when storing structs because
classes
behave like references.
I think in this case, it might make sense to store pointers to structs. So, auto c = R!(Point*)(10); OR alias Point* PointRef; auto c = R!PointRef(10); Let me know if there's something wrong with this approach.
Assume you are using Phobos which returns a range as ranges are the glue keeping Phobos together and leading to a coherent interface. Then there is no way to get a pointer or similar. Your solution does work in cases when I control the storage but that should be rare cases. Additionally using pointers clutters the code I think. In essence: Whenever you are using a range of some struct in Phobos then calling a mutating member function on its elements won't do what you are expecting. You have to resort to copying/moving. I.e. a range's element can only be changed by copying/moving. I wonder how often other Phobos users run into this issue. Only Peter finds this issue to be problematic. When we have ranges everywhere the result may be much more troublesome. Thanks for your reply. Jens
May 04 2012