On Wed, 13 Oct 2010 23:13:43 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Thu, 14 Oct 2010 01:32:49 +0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
A seekable interface is one of those things that's really hard to get
right. In Tango, we eventually got rid of the seekable interface and
just added seek methods to all the low level stream interfaces. The
rationale is that most of the time seekability is not a requirement you
can set when opening a file. You open a file for reading or writing,
but not for seeking. So it's almost necessary that seekability is a
runtime decision (because the OS decides it outside of your control).
There are, of course, streams that will not be seekable (netowork
sockets), but you just throw an exception when seeking such a stream.
The only thing I'd create is a way to determine seekability without
throwing an exception (i.e. a canSeek property). But most of the time
you know whether a stream is seekable without having to check.
Essentially, there is no difference between bool canSeek and
SeekableStream seekable(). However, it's almost always a good idea to
check whether a stream actually supports seeking before doing so, and
seekable() statically enforces you to do so.
Yes and no. It's good to have to check once. It's not good to require
checking on every call. Once you know seeking is supported, you don't
have to keep checking.
You may say a solution is to cache the result of seekable. But that's
awkward also, now you have to maintain two class references to essentially
the same implementation.
Not only that, but I consider that canSeek will be a very rarely used
function. If you have a method that requires seeking, and you check
canSeek, what do you do if it returns false? Probably throw an
exception? Then why not just try seeking and let it throw the exception?
-Steve
