Re: [boost] [gsoc-2013] proposal for approximate string matching

Part A, similarity metrics(use edit distance as an example): template.... (1) (size_type or unsigned) edit_distance(const Range1T&, const Range2T&); (2) (size_type or unsigned) edit_distance(const Range1T&, const Range2T&, (size_type or unsigned) threshold); (3) (size_type or unsigned) edit_distance(const Range1T&, const Range2T&, equal_func); (4) (user-defined type) edit_distance(const Range1T&, const Range2T&, cost);

the cost struct may be like this: template struct cost { V substitution(const T&, const T&) const; V insertion(const T &a) const; V deletion(const T &a) const; }

This seems like a good approach to me.

(5) pair edit_distance_with_operation(const Range1T&, const Range2T&); (6) pair edit_distance_with_operation(const Range1T&, const Range2T&, threshold); (7) pair edit_distance_with_operation(const Range1T&, const Range2T&, equal_func); (8) pair edit_distance_with_operation(const Range1T&, const Range2T&, cost); the "operation" may be a pair<"operator", "position">, where "operator" may be an enum of insertion, deletion and substitution, "position" is an unsigned value.

In the past, I would have said "returning a container on the stack will be an efficiency problem", however with the new "move" semantics, I *think* it will OK if it is implemented properly. I have only read about the new "move" semantics, and not used them, so if I'm wrong about that somebody please set me straight :)