On 2010-01-02 21:46:57 -0500, "Steven Schveighoffer"
<[email protected]> said:
That was the point of the enum. It would be a synthetic difference,
but IMO so is save. If it turns out that the only usable times you
implement save all look like:
auto save() { return *this; }
then save gives you nothing. It's kind of a proof by induction (I think).
You say that algorithm A requires the ability to save the state of a
range. So I define a function save on a range which cannot be saved by
a simple assignment (i.e. a file). I use A on that range, and the
results are not what I expect or kill performance or consume unneeded
resources, I'd rather not use algorithm A on that range, negating the
need to define a save function in the first place.
I think that's what we're going to end up with.
This is making me think...
First, opening files silently whenever an algorithm feels the need to
save its state is just madness. What if the operating system decide to
pop a security window when opening a restricted file? What if the file
has been deleted or replaced in its directory while your program is
still hanging on the old inode?
One might want to save the position in a file in order to be able to
return there later, but when you return there the last thing you
actually want to do is to open the file a second time: what you might
realistically want is to set the position to what it was before,
calling fseek. So perhaps it would be more useful to have both save()
to save the current state (the position in a file), and restore() which
would restore the saved state (returning to the saved position in a
file).
For ranges with reference semantics -- please call them streams! --
save() and restore() would work just as fpos and fseek for files, but
they might also not be available like in a TCP stream or in a
communication channel between threads.
For ranges such as array slices, save and restore would just copy the
range in one or the other direction. The only reason to have them is so
they can be used as streams.
--
Michel Fortin
[email protected]
http://michelf.com/
