On 11/14/2013 2:28 PM, Christopher Kormanyos wrote:
Hi Jeff,
... all the code but the call to perform_algorithm() deal with buffering, which ends up being redundant with the buffering typically provided by client code.
Thank you for this astute observation. Somehow, it never dawned on me that the class-internal buffering can be avoided at the cost of slightly extended zero-buffer and padding calculations for the final (non-modulus-64) block.
It looks like I owe you 64 bytes of precious microcontroller SRAM.
Hmm, where to spend them... I haven't done inventory on block sizes of all of the hash algorithms, but it seems to me the primary interface of the hash types should include: - compile time block size - a function to accumulate a block - a function to accumulate trailing final bytes IMO buffering should be a separate component which could be used to implement the layered convenience functions built upon the primary interface. Then I can use boost math static_lcm to get a min require block size, then my composite hash would make an integral number of calls for each sub-hash. Jeff