Streaming library

[Denis Koroskin]

On Thu, 14 Oct 2010 22:21:37 +0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Thu, 14 Oct 2010 13:42:53 -0400, Denis Koroskin <2korden at gmail.com>  
> wrote:
>
>> On Thu, 14 Oct 2010 21:31:02 +0400, Steven Schveighoffer  
>> <schveiguy at yahoo.com> wrote:
>>
>>> On Thu, 14 Oct 2010 12:10:58 -0400, Andrei Alexandrescu  
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> On 10/14/10 11:01 CDT, Steven Schveighoffer wrote:
>>>>> On Thu, 14 Oct 2010 09:33:54 -0400, Denis Koroskin  
>>>>> <2korden at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Thu, 14 Oct 2010 17:24:34 +0400, Steven Schveighoffer
>>>>>> <schveiguy at yahoo.com> wrote:
>>>>>>
>>>>>>> On Wed, 13 Oct 2010 18:21:16 -0400, bearophile
>>>>>>> <bearophileHUGS at lycos.com> wrote:
>>>>>>>
>>>>>>>> Andrei:
>>>>>>>>
>>>>>>>>> Well casting from void[] is equally awkward isn't it? I'm still
>>>>>>>>> undecided on which is better.
>>>>>>>>
>>>>>>>> See also:
>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=4572
>>>>>>>>
>>>>>>>> Bye,
>>>>>>>> bearophile
>>>>>>>
>>>>>>> That issue is slightly different because std.file.read actually
>>>>>>> creates the buffer. In this cases, the buffer is not created,  
>>>>>>> dup'd,
>>>>>>> concatenated, etc. so void[] offers the most flexibility.
>>>>>>>
>>>>>>> -Steve
>>>>>>
>>>>>> That is also the least safe:
>>>>>>
>>>>>> Object[] objects;
>>>>>> stream.read(objects); // most likely will fill with garbage
>>>>>>
>>>>>> writeln(objects[0]); // access violation
>>>>>>
>>>>>> It's a type subversion that doesn't require casts.
>>>>>
>>>>> Yes, and this is a problem.
>>>>>
>>>>> But on the flip side, requring casts for non-ubyte value types may be
>>>>> too restrictive. Do we want to require casts when the array being  
>>>>> filled
>>>>> is for example utf-8? If so, then won't that disallow such a  
>>>>> function in
>>>>> safe D?
>>>>
>>>> I think a solid idea would be to template streaming interfaces on any  
>>>> type T that has no indirections.
>>>
>>> This is a *great* idea.  This allows you to instantly use whatever  
>>> type you want in all calls you make, and to have the compiler enforce  
>>> it.
>>>
>>> So stream becomes:
>>>
>>> interface Stream(T = ubyte) if (hasNoPointers!T)
>>>
>>> -Steve
>>
>> I still favor a generic StreamReader with a templated T read() method.  
>> I can't think of an example where I would read one type of data from a  
>> stream (unless that type is a char). In many cases I read int N,  
>> followed by and array of floats of size N etc, followed by some other  
>> type. Do I need to reopen streams for that or something?
>
> No, you just use the default (ubyte) and use casts like you said earlier.
>
> But char, wchar, dchar should also be possible types.  I can't see huge  
> needs for using something like uint or float, but it's there for free.
>
>> Besides, typed stream needs to be built of top of buffered stream (not  
>> an unbuffered one). E.g. T might be a big struct, and Stream doesn't  
>> provide a guaranty that it can ready exactly N bytes (think about  
>> socket stream).
>
> Hm... you are right, you'd have to buffer at least one T in order for  
> this to work.  That kind of sucks.  This rules out wchar and char.   
> Maybe it's better to allow all T's where T.sizeof is 1 (this rules out  
> pointer types anyways).  Andrei?
>
> -Steve

What's point of having multiple types that only differ with read  
signature? When would you prefer Stream!(byte) over Stream!(ubyte) or  
Stream!(char)? What's wrong with an adapter that allows you to read any  
kind of data off the stream?

Why do you need to use a Stream directly for reading an array of e.g. ints  
off the stream? Save your time, don't write duplicated code. Use an  
adapter specially provided for that purpose.