You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was confused as to whether the caller must keep the pattern pointed to by the iterators passed to the constructor after the constructor returns. My guess was that once the internal tables were built the pattern would not be needed any more - but that turns out to be wrong. At the least, the docs need to explain this.
A user faced with these three (or four) algorithms will need to choose one. The docs should offer some guidance, e.g. benchmarks or rules-of-thumb, about which to use.
The docs describe some methods that are private to the implementation; why?
Are you referring to the traits class? If so, that section is there because the implementation is a customization point, rather than a private implementation detail.
The current implementation has two options (array and sparse table), and it chooses which one based on the input types - the array is faster, but is really only suitable for character-sized types (which is probably the most common case). The unordered_map is slower, but much more memory efficient for large alphabets.
I guess I didn't make this clear in the documentation. I will see if I can make it better.
Lorenzo Caminiti wrote
11) [WANT] Extend document of Boyer-Moore-Horspool and/or
Knuth-Morris-Pratt with class code, etc to match docs of Boyer-Moore
(interface is listed in the code reference section but not in the
search algorithm section).
[WANT] When using the object interface, is the caller responsible
to keep the pattern in scope until the search object is destructed?
Either way, this requirement should be clearly documented.
Activity
mclow commentedon Sep 24, 2011
Phil Endecott wrote:
mclow commentedon Sep 24, 2011
Are you referring to the traits class? If so, that section is there because the implementation is a customization point, rather than a private implementation detail.
The current implementation has two options (array and sparse table), and it chooses which one based on the input types - the array is faster, but is really only suitable for character-sized types (which is probably the most common case). The unordered_map is slower, but much more memory efficient for large alphabets.
I guess I didn't make this clear in the documentation. I will see if I can make it better.
mclow commentedon Sep 25, 2011
Some implementation details are in the reference:
// private member functions
void build_bm_tables();
template
corpusIter do_search(corpusIter, corpusIter, std::size_t) const;
template<typename Iter, typename Container>
void compute_bm_prefix(Iter, Iter, Container &);
void create_suffix_table(patIter, patIter)
mclow commentedon Sep 30, 2011
Lorenzo Caminiti wrote
11) [WANT] Extend document of Boyer-Moore-Horspool and/or
Knuth-Morris-Pratt with class code, etc to match docs of Boyer-Moore
(interface is listed in the code reference section but not in the
search algorithm section).
mclow commentedon Sep 30, 2011
to keep the pattern in scope until the search object is destructed?
Either way, this requirement should be clearly documented.