The review of std.hash package

[Regan Heath]

On Thu, 16 Aug 2012 21:25:55 +0100, deadalnix <deadalnix at gmail.com> wrote:

> Le 09/08/2012 11:48, Johannes Pfau a écrit :
>> Am Wed, 08 Aug 2012 12:31:29 -0700
>> schrieb Walter Bright<newshound2 at digitalmars.com>:
>>
>>> On 8/8/2012 12:14 PM, Martin Nowak wrote:
>>>> That hardly works for event based programming without using
>>>> coroutines. It's the classical inversion-of-control dilemma of
>>>> event based programming that forces you to save/restore your state
>>>> with every event.
>>>
>>> See the discussion on using reduce().
>>>
>>
>> I just don't understand it. Let's take the example by Martin Nowak and
>> port it to reduce: (The code added as comments is the same code for
>> hashes, working with the current API)
>>
>> int state; //Hash state;
>>
>> void onData(void[] data)
>> {
>>       state = reduce(state, data); //copy(data, state);
>>       //state = copy(data, state); //also valid, but not necessary
>>       //state.put(data); //simple way, doesn't work for ranges
>> }
>>
>> void main()
>> {
>>       state = 0; //state.start();
>>       auto stream = new EventTcpStream("localhost", 80);
>>       stream.onData =&onData;
>>       //auto result = hash.finish();
>> }
>>
>> There are only 2 differences:
>>
>> 1:
>> the order of the arguments passed to copy and reduce is swapped. This
>> kinda makes sense (if copy is interpreted as copyTo). Solution: Provide
>> a method copyInto with swapped arguments if consistency is really so
>> important.
>>
>> 2:
>> We need an additional call to finish. I can't say it often enough, I
>> don't see a sane way to avoid it. Hashes work on blocks, if you didn't
>> pass enough data finish will have to fill the rest of the block with
>> zeros before you can get the hash value. This operation can't be
>> undone. To get a valid result with every call to copy, you'd have to
>> always call finish. This is
>> * inefficient, you calculate intermediate values you don't need at all
>> * you have to copy the hashes state, as you can't continue hashing
>>    after finish has been called
>>
>> and both, the state and the result would have to fit into the one value
>> (called seed for reduce). But then it's still not 100% consistent, as
>> reduce will return a single value, not some struct including internal
>> state.
>
> I'm pretty sure it is possible to pad and finish when a result is  
> required without messing up the internal state.

Without copying it?  AFAICR padding/finishing mutates the state, I mean,  
that's the whole point of it.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/