So what if the hash classes were written such that this were the default behavior? Specifically that finalize copies the message block state, returns the final digest to the user, and leaves the engine ready to continue processing the message digest. We can still clear the message block state in the destructor, leaving the postconditions of the class the same at the end of its lifetime. For most use cases things would be no different for the user, but there would be much greater flexibility of use without adding more APIs.
I view this as a design choice.
The tried-and-true init --- digest --- finalize mechanism actually
stems from a procedural-language approach. This is because
explicit initialization or finalization (as you mention) can be
eliminated with class-internal flags. So maybe an object-oriented
design needs a slightly altered paradigm.
Maybe it would be a good idea to mimic the interface of
Boost.Crc, in so far as there are analogies such as init,
final XOR --> finalize, etc.
I think these kinds of design choices such as the interface,
the class template parameters, etc. generally should be
agreed upon up front.
Sincerely, Chris.
On Thursday, November 14, 2013 5:31 AM, foster brereton
On 11/13/13 6:03 PM, Christopher Kormanyos wrote: ...
There is another interface detail that can lead to a useful flexibility. In addition to init --- digest --- finalize scheme, some use cases need to finalize a running hash, yet retain its state. This can be accomplished with a kind of function such as "get_result_and_nochange_the_state". In this way, a running hash final result can be obtained, but more bytes can be fed into the hash. This can be a constant member function, as a copy of the hash object needs to be made.
I've this exact situation - currently two hashes are maintained.
So what if the hash classes were written such that this were the default behavior? Specifically that finalize copies the message block state, returns the final digest to the user, and leaves the engine ready to continue processing the message digest. We can still clear the message block state in the destructor, leaving the postconditions of the class the same at the end of its lifetime. For most use cases things would be no different for the user, but there would be much greater flexibility of use without adding more APIs. - foster _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost