## D - [experts] opComma

- Manfred Nowak (31/31) Feb 19 2004 I am playing with a hashing function `f'.
- Sean Kelly (21/21) Feb 19 2004 Why not make 'f' a function object?
- Manfred Nowak (7/9) Feb 19 2004 [...]
- Sean Kelly (3/11) Feb 19 2004 But where is the explicit signalling? The hash is computed on-demand.
- Manfred Nowak (11/12) Feb 19 2004 Ahh, I got your proposal wrong. The `f.hash' is intended as a pure

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.

Feb 19 2004

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

Feb 19 2004

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.

Feb 19 2004

Manfred Nowak wrote:Sean Kelly wrote:But where is the explicit signalling? The hash is computed on-demand. Seanf( 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.

Feb 19 2004

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.

Feb 19 2004