On Sep 7, 2017, at 12:40 PM, Vinnie Falco via Boost
On Thu, Sep 7, 2017 at 9:26 AM, Howard Hinnant via Boost
wrote: endian taken into account here:
I use endianness only as an easily understood example of an issue that makes the needs of a cryptographic hash interface different from an unordered container hash interface. There are other issues, which require a move involved discussion than I think is appropriate in this thread. For example, we cannot have distinct cryptographic and non-cryptographic serialization algorithms for the same type (using n3980).
Demo for distinct serialization algorithms for varying hashers:
#include "hash_append.h"
#include "sha256.h"
#include "fnv1a.h"
#include <iostream>
class X
{
std::array
The bottom line is that n3980 needs to go through more iteration and study with respect to its usage for cryptographic hash algorithms before we can state that the interface is well suited for it.
I welcome and encourage more study and discussion in any context, thread or list. My only motivation here is to dispel mistaken believes that the current hash_append infrastructure can not handle issues such as endian or alternate serialization algorithms for different hashers. Admittedly, the latest proposal (N3980) is sorely in need of updating and likely doesn’t have the latest details of the implementation at https://github.com/HowardHinnant/hash_append . And thanks for the shout-out to this lib earlier in this thread. Howard