On Fri, 22 May 2009 11:48:34 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Steven Schveighoffer wrote:
And finally, if you copy such a range, the buffer might be copied while
the stream itself may not. this could result in strange garbage data.
I don't understand this. You could make sure copy does the right thing.
I'll respond to this one point separately.
consider you have a range with a statically defined buffer (not a
heap-allocated):
struct range
{
uint buf;
FILE *source;
}
Let's assume the data in the source reads 1,2,3,4,5
The buffer contains 1, and 2,3,4,5 is still on the source
Without any alterations, copying the range copies the buffer, so now one
instance of the range will read correctly, say:
1,2,3
and the copy will read:
1,4,5
Now, let's say when copying, we kill the buffer from the source range,
re-run our example, and it now correctly reads:
1,2,3
4,5
But now, you might reorder the data in a strange way:
auto r2 = r1; // r1 now has no buffer, r2 contains '1'
output(take(r1, 3));
output(take(r2,2));
outputs:
2,3,4
1,5
This can be a problem if you are depending on order. This isn't a likely
scenario, but without a static buffer per range, you don't have any
reordering issues.
I just think having weird bugs like that will be troublesome in certain
cases. Calling it 'expected behavior' is not going to help matters.
In addition, without a buffer to worry about, the code becomes much
simpler.
-Steve
