Namespace for a Boost Hashing Library
I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community. The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256). Some possibilities: - boost::hashes Following the usual boost method of a plural namespace when a class exists. - boost::hash_algo or boost::hash_algorithms Following the string_algo precedent. - boost::hashing or boost::hashing_algorithms Using a gerund for a change. - boost::digests or boost::message_digest Using the name of the result of a hash, rather than the process. - boost::fingerprint (or boost::dactylogram) An alternative name for the result of a hash. - Something else better that you come up with Some complaints raised about those options: - boost::hashes or boost::hashing or boost::digests It's hard to remember when namespaces aren't singular as usual (especially for the first two, when the library doesn't provide anything named "hash"). - boost::hash_algo It would be better to not use an abbrev. - boost::hash_algorithms or boost::hashing_algorithms or boost::message_digest Shorter namespaces are generally preferred, where possible. - boost::fingerprint (or boost::dactylogram) Implies a particular use and certain minimum length of result. Which one(s) do you prefer or dislike? Thanks, ~ Scott McMurray
I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community.
The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256).
It seems like these are all natural allies to the stuff already in boost::hash, what's the issue in also using that name and extending the existing hash function library? Just my 2c worth, John.
On 9 May 2010 12:25, John Maddock <boost.regex@virgin.net> wrote:
It seems like these are all natural allies to the stuff already in boost::hash, what's the issue in also using that name and extending the existing hash function library?
Sorry, I should have been more clear. boost::hash is a class template like std::tr1::hash, not a namespace.
From <boost/functional/hash/hash_fwd.hpp>:
namespace boost { template <class T> struct hash; } ~ Scott McMurray
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Sunday, May 09, 2010 5:25 PM To: boost@lists.boost.org Subject: Re: [boost] Namespace for a Boost Hashing Library
I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community.
The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256).
It seems like these are all natural allies to the stuff already in boost::hash, what's the issue in also using that name and extending the existing hash function library?
And there are other related hash functions like ISBN and Visa card check characters that could usefully be provided in the same name/space? (BTW Is there interest in these functions for a GSoC?) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On 11/05/2010 7:23 PM, Paul A. Bristow wrote:
And there are other related hash functions like ISBN and Visa card check characters that could usefully be provided in the same name/space?
To further that, I think Boost.CRC would also be another candidate that could be "rolled" into this hash library.
On 11 May 2010 07:57, Arash Partow <arash@partow.net> wrote:
To further that, I think Boost.CRC would also be another candidate that could be "rolled" into this hash library.
I added a wrapper around Boost.CRC yesterday, in fact. assert(compute_digest<crc32_png>("abc") == "352441c2"); I would be hesitant to absorb it fully, however, as it seems from the header that much work went into workarounds for various old compilers, and I'd be surprised if this hash library worked in all those compilers (due to use of partial specifications, SFINAE, etc).
On 11 May 2010 05:23, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
And there are other related hash functions like ISBN and Visa card check characters that could usefully be provided in the same name/space?
Things are set up to give a digest in a way that can easily and portably be read from and written to an octet stream (like a socket or file) as a check on an entire message. There's a fundamental assumption that the input could be arbitrarily long, and currently the output is assumed to be a multiple of 8 bits. So in theory yes, but practically a different set of concepts might be better, given the different properties of the inputs and the small size of the outputs for things that are more like parity checks.
(BTW Is there interest in these functions for a GSoC?)
New hash functions would definitely be possible as a GSoC, but it would almost certainly have to be plural. With the concepts and infrastructure already in place, adding a new checksum is usually a pretty simple task.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Scott McMurray Sent: Tuesday, May 11, 2010 4:21 PM To: boost@lists.boost.org Subject: Re: [boost] Namespace for a Boost Hashing Library
On 11 May 2010 05:23, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
And there are other related hash functions like ISBN and Visa card check characters that could usefully be provided
in
the same name/space?
Things are set up to give a digest in a way that can easily and portably be read from and written to an octet stream (like a socket or file) as a check on an entire message. There's a fundamental assumption that the input could be arbitrarily long, and currently the output is assumed to be a multiple of 8 bits.
So in theory yes, but practically a different set of concepts might be better, given the different properties of the inputs and the small size of the outputs for things that are more like parity checks.
(BTW Is there interest in these functions for a GSoC?)
New hash functions would definitely be possible as a GSoC, but it would almost certainly have to be plural. With the concepts and infrastructure already in place, adding a new checksum is usually a pretty simple task.
Well there are several in very common use, for example those listed at http://www.augustana.ab.ca/~mohrj/algorithms/checkdigit.html Verhoeff's Dihedral Group D5 Check scheme is a bit more complicated than some. And *testing* is a vital feature of Boost quality software - and quite a bit of work. I would have thought that many people who could make use of these - perhaps in ways that are not common at present (part numbers, error checked GPS coordinates ...). But what do others think? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On 11 May 2010 12:25, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
Well there are several in very common use [...] I would have thought that many people who could make use of these - perhaps in ways that are not common at present (part numbers, error checked GPS coordinates ...).
But what do others think?
There's definitely a library there, and as much of it would be concept distilling, it might fit very well in GSoC. My disinterest is simply in the context of the Hash library, where I don't think they fit. (Input format is different, output format is different, and expected incidental errors are different.)
On 09/05/10 17:19, Scott McMurray wrote:
I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community.
The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256).
Some possibilities:
- boost::hashes Following the usual boost method of a plural namespace when a class exists.
I've always thought plurals were better for namespaces anyway, so I like boost::hashes. John Bytheway
On 05/09/2010 10:19 AM, Scott McMurray wrote:
I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community.
The intention for the library is to provide concepts and some implementations for checksums (like CRC32), plain hash functions (for hash tables), and cryptographic hash functions (like MD5 or SHA-256).
How about boost::crypto::hash to provide a foundation for further crypto work in Boost. Otherwise boost::hash_algo could work. Rob
I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community.
Stealing from Wikipedia... "The values returned by a hash function are called hash values, hash codes, hash sums, checksums or simply hashes." ... what about boost::hash_codes. Most other things that have been suggested sound fine. However, abbreviating algorithm as algo as part of hash_algo drives me batty. It doesn't break the word on a syllable. Moreover, said aloud it sounds like either a cheesy superhero or a poorly made automobile. - Rhys
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/09/2010 11:05 PM, Rhys Ulerich wrote: [...]
Stealing from Wikipedia...
"The values returned by a hash function are called hash values, hash codes, hash sums, checksums or simply hashes."
... what about boost::hash_codes. [...]
If a relative newcomer is allowed an opinion, that sounds like a good one to me. hash_values works too (and I personally like it slightly more). - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvnj7cACgkQp9x9jeZ9/wQboQCglwXP6nU2uGmxAVwhRnN/MZGh BMgAnRVttgZSUlLVXDKdB7omWaFCW8Pu =bdoN -----END PGP SIGNATURE-----
On Sun, 2010-05-09 at 12:19 -0400, Scott McMurray wrote:
I initially used boost::hash, forgetting that the unordered containers have already claimed that name. A number of alternatives have been proposed, so I hoped to get some thoughts from the wider community. [...] - boost::hash_algo or boost::hash_algorithms Following the string_algo precedent.
What is the "string_algo precedent"? The string algorithms are in headers under boost/algorithm/string/, and live in namespace boost::algorithm (but are also pulled into namespace boost). [...]
- boost::hash_algo It would be better to not use an abbrev. - boost::hash_algorithms or boost::hashing_algorithms or boost::message_digest Shorter namespaces are generally preferred, where possible.
If the name "algorithm" is going to be in the namespace at all, wouldn't it make more sense to put it under boost::algorithm (either directly, or as a nested namespace)? Phil -- Phil Richards, <news@derived-software.ltd.uk>
On 11 May 2010 05:40, Phil Richards <news@derived-software.ltd.uk> wrote:
What is the "string_algo precedent"? The string algorithms are in headers under boost/algorithm/string/, and live in namespace boost::algorithm (but are also pulled into namespace boost).
Ah, my mistake. I just saw it in the URL and assumed it meant something: http://www.boost.org/doc/html/string_algo.html
If the name "algorithm" is going to be in the namespace at all, wouldn't it make more sense to put it under boost::algorithm (either directly, or as a nested namespace)?
That's a good point. The only quibble I'd have is that boost::algorithm::hash::digest looks like a verb, and I do need the one noun.
Scott McMurray wrote:
On 11 May 2010 05:40, Phil Richards <news@derived-software.ltd.uk> wrote:
If the name "algorithm" is going to be in the namespace at all, wouldn't it make more sense to put it under boost::algorithm (either directly, or as a nested namespace)?
That's a good point. The only quibble I'd have is that boost::algorithm::hash::digest looks like a verb, and I do need the one noun.
boost::algorithm::hashes "hashes" can still be taken as a verb, but we're predisposed to think of namespaces as things (they are scopes), so we're likely to consider "hashes" as the plural of the noun "hash." boost::algorithm::hashing That isn't a noun, but clearly describes the contents as related to hashing algorithms. I rather prefer that. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (10)
-
Arash Partow -
Chad Nelson -
John Bytheway -
John Maddock -
Paul A. Bristow -
Phil Richards -
Rhys Ulerich -
Rob Riggs -
Scott McMurray -
Stewart, Robert