I am playing with a hashing function `f'.

`f' is able to yield a hash value from memory areas of unrestricted
length. Because relevant memory areas may be spread over main
memory and explicitly concatenating those areas is inefficient
`f' must be able to implicitely concatenate those areas.

So, if there are `n' memory areas `area.1', `area.2', .., `area.n',
instead of calling `f( area.1 ~ area.2 ~ ... ~ area.n)', let thereby be
`~' the correct concatenation operator, `n' subsequent calls `f(area.1)',
`f(area.2)', ..., `f(area.n)' must be executed.

Now assume, that it would be inefficient to compute the hash value at
every call. Then only the last call should compute it. This can be
signalled in several ways:
  hash= f( area.n, COMPUTE);
  f(area.n); hash= f(null);
  f(area.n); hash= f();
  ...

Disadvantage of this is, that the signalling of the final call must always be present, even when only one memory area has to be hashed. I do not see a solution that does not need any signalling except overloading the comma operator:

  struct HashFunc{
    void opComma( areaType ...){ ... accumulate data }
    uint opCall( areaType ...){ ... last data item, compute hash value }
  } HashFunc f;

  hash= f(area.1);               //only one area
  hash= (f(area.1), f(area.2), ... , f(area.n)); //several areas
  hash= f(area.1), f(area.2), ... , f(area.n); // error: void value

I believe that this of interest in several data accumulating areas.

So long.

Why not make 'f' a function object?

class compute_hash
{
public:
    void operator()( char[] str )
    {
        // store reference or compute partial hash or some such
    }

    int hash()
    {
        // compute hash if not yet computed
        // return hash value
    }
};

Then to use it:

compute_hash f;
f( area.1 ); f( area.2 ); ... f( area.n );
int hash = f.hash;

I'm sure it would be possible to make the interface even cleaner, but you get the idea.


Sean

Sean Kelly wrote:

[...]
> f( area.1 ); f( area.2 ); ... f( area.n );
> int hash = f.hash;
[...]

I see. But this is only one of the many ways _with_ explicit signalling the end of the data collecting phase. I am searching for something without this explicit signalling.

So long.

Manfred Nowak wrote:
>
> Sean Kelly wrote:
> 
>>f( area.1 ); f( area.2 ); ... f( area.n );
>>int hash = f.hash;
> 
> I see. But this is only one of the many ways _with_ explicit signalling
> the end of the data collecting phase. I am searching for something without
> this explicit signalling.

But where is the explicit signalling?  The hash is computed on-demand.


Sean

Sean Kelly wrote:

> But where is the explicit signalling?  The hash is computed on-demand.

Ahh, I got your proposal wrong. The `f.hash' is intended as a pure computing function. But then you need a third definition for the reset of the internal data to an initial value.

By overloading the comma the user of the class would be reliefed from the burdon to remember the two or even three syntactical variants.

But I just notice, that I open the door to a further class of notational errors: accidentically interchanging a comma with a semicolon.

Thank you for your patience. I end evaluating this idea with negative result.

So long.