-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2010 12:44 PM, Scott McMurray wrote:
I agree with your opinion, with a slight variation: don't reset the accumulator until the user explicitly requests it. It seems counterintuitive, though I'm sure it could be made obvious with the proper function naming.
Why do you prefer that method? Since get_digest adds padding, calling get_digest or process_byte again without a reset doesn't provide anything useful. Also, the reset is just a few copies, completely negligible compared to the cost of the one or two block compression, so omitting it saves nothing.
Agreed, on all points. But unless the function is named such that it's very obvious that it resets the object as well as returns the hash value, people will be surprised that it reset itself when they didn't tell it to.
Is there a particular reason to separate the two (conceptually)? A Boost.CryptographicHash library, covering those and several other commonly used ones, seems more appealing. They would, of course, still be *logically* separate, they'd just be under the same umbrella name, and share the same interface.
They should definitely use the same interface. As mentioned, they need a Concept to which generic code can be written. I mostly just had them separate because the precedent is Boost.CRC, not Boost.ErrorDetectingCode.
Off the top of my head, I think Boost.CRC supports my argument, since I believe it includes Adler codes. They're a form of CRC, but aren't what most programmers think of when you say CRC.
I'll contribute code for several more formats (MD2, RIPEMD 128/160/256/320, Tiger 128/160/192, Tiger2 128/160/192, and Whirlpool, all byte-oriented only), if you're interested. They probably need some work (they were written several years ago), but the core code is sound.
More formats would be great, and is part of the reason for separate libraries, since I'm certain that others will want to add more formats, and shouldn't have to go through the first person to propose some, as Boost guidelines prefer for additions to existing libraries.
I don't know the details, but there may be precedent for an umbrella library name with different but related parts by different authors: Boost.Math.
Speaking of byte-oriented, one great bit about templating is that the preprocessing stage can be written generically and fed with different-size types (so bit, byte, and different words all work) and to different backends, so SHA-1/256/384/512 all use the same preprocessor. It's still efficient, too -- it works out the same or a few percent faster than the version Andy found for boost/uuid/sha1.hpp.
Adding a few more algorithms will be an important test of this genericity, though.
Just let me know if you'd like to see the code... and don't laugh too hard when you do, I was young(er) and foolish when I wrote it. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku6WeMACgkQp9x9jeZ9/wSd0gCfSn/pvVjHfuCws1dtAWErhPCS wGcAn2l89EdKajIUiaE6s8saKlTXtO04 =Pc0g -----END PGP SIGNATURE-----