August 09, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | On 2012-08-09 15:02, Johannes Pfau wrote: > What annoys me is that as long the function only supported arrays, it > didn't need templates _at all_. So template bloat for arrays = 0. But > adding range support means the version dealing with arrays now has to > be a template as well(which is probably a bug, can't overload template > and non template function) and will produce extra code for every array > type. I just think adding range support shouldn't cause the array code > to change in any way. A workaround is to make the non-template function to a template, with no arguments. This should only cause one instantiation: void foo (T) (T t) if (/* some constraint making it not match "int" */); void foo () (int x); -- /Jacob Carlborg |
August 09, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | On 09-Aug-12 14:15, Regan Heath wrote: > On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see@klickverbot.at> > If the range/hash object stores the current state and returns this as > the result of hashreduce, it would be chainable. If it also had a > "Digest" property/method which performed finish on a /temporary copy/ of > the state it would almost be as automatic as reduce. There would still > be a manual step to get the result, but it would be analogous to calling > toString on any range object to output it's "value". The Digest > property/method would not modify the internal state, and could be called > at any time between (not sure there is a point to this) or after chained > hashreduce operations. struct ShaState { ... alias ubyte[16] getDidgest(); } Problem is: too much magic, spoils auto x = reduce(...); idiom. To be brutally honest I don't see what in std.hash doesn't fit "range component" model: - it works on input ranges via convenient adaptor (or would work soon) - it has output _ranges_. What's not to like about it? That it doesn't fit general reduce algorithm? I'm not convinced it's important. In the same vane you may try to shoehorn symmetric cyphers to follow map interface because conceptually it does 1:1 conversion. Now important thing: just look at other output ranges. They either require extra call (see Appender .data) or horrendously slow and ugly see lockingTextWriter/Reader. -- Dmitry Olshansky |
August 09, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | On 09-Aug-12 20:32, Dmitry Olshansky wrote: > On 09-Aug-12 14:15, Regan Heath wrote: >> On Thu, 09 Aug 2012 10:59:47 +0100, David Nadlinger <see@klickverbot.at> > >> If the range/hash object stores the current state and returns this as >> the result of hashreduce, it would be chainable. If it also had a >> "Digest" property/method which performed finish on a /temporary copy/ of >> the state it would almost be as automatic as reduce. There would still >> be a manual step to get the result, but it would be analogous to calling >> toString on any range object to output it's "value". The Digest >> property/method would not modify the internal state, and could be called >> at any time between (not sure there is a point to this) or after chained >> hashreduce operations. > > struct ShaState > { > ... > alias ubyte[16] getDidgest(); > } Too fast.. should have been: ubyte[16] getDidgest(); alias getDigest this; -- Dmitry Olshansky |
August 09, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | On Thursday, 9 August 2012 at 16:37:57 UTC, Dmitry Olshansky wrote:
> Too fast.. should have been:
> ubyte[16] getDidgest();
> alias getDigest this;
I have been thinking about using AliasThis as well, but the problem is that precisely the use case this is meant to enable (i.e. »snapping together components«, like Walter said) tends to get broken in subtle ways due to the use of template functions/type inference.
David
|
August 09, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On Thursday, August 09, 2012 18:46:59 David Nadlinger wrote:
> On Thursday, 9 August 2012 at 16:37:57 UTC, Dmitry Olshansky
>
> wrote:
> > Too fast.. should have been:
> > ubyte[16] getDidgest();
> > alias getDigest this;
>
> I have been thinking about using AliasThis as well, but the problem is that precisely the use case this is meant to enable (i.e. »snapping together components«, like Walter said) tends to get broken in subtle ways due to the use of template functions/type inference.
Yeah. alias this can be very useful, but it's very dangerous when it comes to templated functions, because it's very easy to make assumptions when writing those functions which hold great when using the actual type but do funny things when alias this comes into play. And unfortunately, I don't think that it's something that's at all well understood. It's probably one of those things that we as a community need to get a better grip on. Just imagine how bad it would be though if D allowed as many implicit conversions as C++ does...
- Jonathan M Davis
|
August 10, 2012 std.hash review: Update 1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | I implemented some of the suggestions, here's the list of changes: Changelog: * Add a new overload to the 'digest' function which accepts an InputRange * Add a new convenience function 'hexDigest' which works just like 'digest', but returns a string (also works with InputRanges) An open question is whether md5StringOf/md5HexOf aliases should be added (similar to md5Of)? * Add a new convenience function 'startDigest' which returns an initialized digest * New example for file hashing in idiomatic D * Documented that Digests are always OutputRanges * Added new examples using std.algorithm.copy & OutputRange interface * Small optimization in toHexString & hexDigest: do not allocate if possible TODO: * move the package to std.digest (unless there are objections): std.hash.hash --> std.digest.digest std.hash.md --> std.digest.md std.hash.sha --> std.digest.sha std.hash.crc --> std.digest.crc * make sure the docs are consistent regarding names (digest vs. hash) Code: https://github.com/jpf91/phobos/tree/newHash/std/hash https://github.com/jpf91/phobos/compare/master...newHash Docs: http://dl.dropbox.com/u/24218791/d/phobos/std_hash_hash.html http://dl.dropbox.com/u/24218791/d/phobos/std_hash_md.html http://dl.dropbox.com/u/24218791/d/phobos/std_hash_sha.html http://dl.dropbox.com/u/24218791/d/phobos/std_hash_crc.html |
August 12, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christophe Travert | See the new thread Andrei started entitled "finish function for output ranges". I think this discussion has clearly discovered a shortcoming in the current range design, and Andrei has a proposed solution. |
August 15, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote: >> In this case, it needs to work like a reduce algorithm, because it is a reduce algorithm. Need to find a way to make this work. > > Hash functions are _not_ analogous to reduce(), because the operation performed by reduce() is stateless, whereas hash functions generally have some internal state. An example of stateless hash in .net: http://msdn.microsoft.com/en-us/library/xa627k19.aspx |
August 15, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 15-Aug-12 11:41, Kagamin wrote: > On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote: >>> In this case, it needs to work like a reduce algorithm, because it is >>> a reduce algorithm. Need to find a way to make this work. >> >> Hash functions are _not_ analogous to reduce(), because the operation >> performed by reduce() is stateless, whereas hash functions generally >> have some internal state. > > An example of stateless hash in .net: > http://msdn.microsoft.com/en-us/library/xa627k19.aspx AFAIK it'a method of HashAlgorithm Object. http://msdn.microsoft.com/en-us/library/c06s9c55 It also includes TransformBlock & TransformFinalBlock. It does contain state of course. |
August 15, 2012 Re: The review of std.hash package | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On Wednesday, 15 August 2012 at 07:41:20 UTC, Kagamin wrote: > On Thursday, 9 August 2012 at 09:59:48 UTC, David Nadlinger wrote: >> Hash functions are _not_ analogous to reduce(), because the operation performed by reduce() is stateless, whereas hash functions generally have some internal state. > > An example of stateless hash in .net: > http://msdn.microsoft.com/en-us/library/xa627k19.aspx http://msdn.microsoft.com/en-us/library/system.security.cryptography.hashalgorithm.state David |
Copyright © 1999-2021 by the D Language Foundation