Streaming library

Steven Schveighoffer schveiguy at yahoo.com
Thu Oct 14 11:21:37 PDT 2010


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


More information about the Digitalmars-d mailing list