Streaming library

[Steven Schveighoffer]

On Wed, 13 Oct 2010 23:13:43 -0400, Denis Koroskin <2korden at gmail.com>  
wrote:

> On Thu, 14 Oct 2010 01:32:49 +0400, Steven Schveighoffer  
> <schveiguy at 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