----- Original Message -----
- My experience has been that early termination is best expressed in terms of RAM, i.e. the caller could indicate a maximum amount of RAM, in bytes, rather than a maximum for the edit cost. You can probably convert between them via sizeof.
As I see it, there are three early-termination options on the table: _max_cost _max_memory _max_time Each of those has its potential utility. It is easy to code them, and I have techniques to implement them so that they cost nothing when they aren't invoked: https://gist.github.com/erikerlandson/7455677 A few questions on my mind: 1) Adding any further parameters will require increasing BOOST_PARAMETER_MAX_ARITY from its default value. Is it best to just do that automatically in edit_distance.hpp, or explain to the user that they should do it? 2) Currently, _max_cost comes paired with the _max_cost_exception flag. Adding _max_memory and _max_time would seem to imply _max_memory_exception and _max_time_exception. So now we have six optional parameters governing early-termination conditions. Not sure I really have a problem with that, but it's getting populous. It is possible that the '*_exception' flags could be collapsed to a single flag, say '_terminate_exception'. I'm not sure how likely it is that a person would want to use fallback for one condition, and throw an exception on another. 3) maybe better names would be _terminate_cost, etc? 4) I see that there are now even monadic approaches to exception handling: boost::make_optional(). Is exception throwing deprecated? Does make_optional require c++11? Does _terminate_exception change from a boolean flag to an enumerated type: { fallback, exception, optional }?