Boost C++ Libraries: Ticket #12552: Change of the interface of Searching Algorithms breaks client code https://svn.boost.org/trac10/ticket/12552 <p> I am using Boyer-Moore Search from the Algorithm component. The change of search functions interface introduced by this commit <a class="ext-link" href="https://github.com/boostorg/algorithm/commit/205f5ff4bbb00ece289892089a6c94c975e97ca2"><span class="icon">​</span>https://github.com/boostorg/algorithm/commit/205f5ff4bbb00ece289892089a6c94c975e97ca2</a> broke my code. Because now search functions return pair of iterators instead of one iterator. Documentations does not reflect these chenges: <a href="http://www.boost.org/doc/libs/1_62_0/libs/algorithm/doc/html/algorithm/Searching.html#the_boost_algorithm_library.Searching.BoyerMoore">http://www.boost.org/doc/libs/1_62_0/libs/algorithm/doc/html/algorithm/Searching.html#the_boost_algorithm_library.Searching.BoyerMoore</a> </p> <p> Please explain why are you making changes which are not backward compatible and break users code? </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12552 Trac 1.4.3 Marshall Clow Wed, 26 Oct 2016 18:28:14 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/12552#comment:1 https://svn.boost.org/trac10/ticket/12552#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> First, I apologize for the lack of documentation of the changes. That has been corrected, and will appear in the 1.63.0 release, along with some porting notes. You can see those docs in the develop branch now. </p> <p> As for "why did I make this change", it's because the previous interface was throwing away useful information - to be precise, the end of the matched range. If you know the length of the pattern that you are searching for, and you have random-access iterators, then recovering the end of the matched range is simple and cheap. However, that's not always the case. Consider a matcher that matches against a regular expression. </p> <p> I wrote a blog post about this titled "sometimes you get things wrong" here: <a class="ext-link" href="https://cplusplusmusings.wordpress.com/2016/02/01/sometimes-you-get-things-wrong/"><span class="icon">​</span>https://cplusplusmusings.wordpress.com/2016/02/01/sometimes-you-get-things-wrong/</a> </p> Ticket antoinep92@… Wed, 02 Nov 2016 13:59:19 GMT <link>https://svn.boost.org/trac10/ticket/12552#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/12552#comment:2</guid> <description> <p> Just for people looking for the porting notes mentioned by marshall, they're available on github here: <a class="ext-link" href="https://github.com/boostorg/algorithm/blob/develop/doc/boyer_moore.qbk"><span class="icon">​</span>https://github.com/boostorg/algorithm/blob/develop/doc/boyer_moore.qbk</a> (markup version -- haven't been able to find compiled html). </p> <p> (please note that the version on SVN trunk is not up to date) </p> </description> <category>Ticket</category> </item> </channel> </rss>