boostorg / algorithm Goto Github PK

View Code? Open in Web Editor NEW

109.0 109.0 108.0 3.77 MB

Boost.org algorithm module

Home Page: http://boost.org/libs/algorithm

License: Boost Software License 1.0

C++ 91.72% HTML 4.44% Max 3.74% CMake 0.10%

algorithm's People

Contributors

Stargazers

Watchers

Forkers

qs8607a oyefremov pabigot erikerlandson danieljames sanderbog jeremy-murphy chris-paprocki fpelliccioni wygos rameshkrishnan712 mkurdej tmp-reg jzmaddock rogeriodossantos tempoz hexlul automeka madmongo1 limbolily crossbuild trel scopeinfinity apolukhin nigels-com aldonin kundor autodesk-forks zamazan4ik marcelraad lllshamanlll danielae xltools elzair very-cool-name njlr lastique uppi praetorian20 malterlib bazelboost myestro samuela devindusoft pandinosaurus p8499 leeyangg mike-devel felixpetriconi jeking3 buckaroo-pm boostandroid sbreitstein tinko92 samcday tlanc007 wdlctc tapaswenipathak jinhang2008 pointertoeric kojoley yatharth77 madmongo1-boostorg rkyadav-643 zhaohui0923 warlockz f3rm4rf3r vgvassilev abhishekkujur1307 xtrememapping gribdesbois opensourceeda fieryswampshire longgang vaxobovavazbek libbooze ekra-ltd jgopel jeffgarland tzlaine jingliang2005 ishandutta2007 halis-sh samd2 fanquake isabella232 denzor200 clayne amanuel-negussie redcod glywk gtton romain-geissler-1a testmigrator xiovlad roibarkan ka-de seanpm2001 0xfeedc0de64 sam-caldwell

algorithm's Issues

boost::algorithm::split_regex doesn't work with boost::u32regex.

I want to split a UTF-8 string into tokens. However it looks like that split_regex() failed and just return original string. I also tried u32regex_replace() and it indeed replaced successfully.

src.cpp:

// CutWord.cpp : This file contains the 'main' function. Program execution begins and ends there.
//

#include <iostream>
#include<vector>
#include<string>

#include <boost/algorithm/string.hpp>
#include<boost/algorithm/string/regex.hpp>
#include <boost/regex/icu.hpp> 
#include<regex>

using namespace std;

int main()
{
	string str="数学。数学。数学。";
	
	//Split
	vector<string> vs;
        //regexU3 stores expression.
	boost::u32regex regexU32= boost::make_u32regex("。");
	boost::split_regex(vs, str,regexU32);
	cout<<vs.size()<<endl; //only return 1.
	
	//Check if u32regex_replace works.
	string nsub=".";
	string nstr=u32regex_replace(str, regexU32, nsub);
	cout<<nstr<<endl;
};

CMakeLists.txt:

cmake_minimum_required(VERSION 3.10)
project(main)
set(CMAKE_C_COMPILER /usr/bin/gcc CACHE PATH "" FORCE)
set(CMAKE_CXX_COMPILER /usr/bin/g++ CACHE PATH "" FORCE)

include_directories("/usr/local/include")
include_directories("./include")

add_executable(mp src.cpp)

#ICU
find_package(ICU COMPONENTS i18n  io dt in uc)
target_link_libraries(mp ${ICU_LIBRARIES})

#boost
find_package( Boost COMPONENTS regex)
include_directories(${Boost_INCLUDE_DIR})
link_directories(${Boost_LIBRARY_DIR})
target_link_libraries( mp ${Boost_LIBRARIES} )

target_compile_features(mp PUBLIC cxx_std_20)
add_custom_command(TARGET mp POST_BUILD
	COMMAND echo "----------------------------------------------"
	COMMAND ./mp
	COMMAND echo "----------------------------------------------")

Any plan for C++20 container related algorithms such as std::erase(_if)?

In the past, since boost is a much larger and much heavier library, using boost is always more convience than using pure STL.
But with new standards comes, STL has its own std::erase_if or something else (better range support etc.) for different STL containers.
As a result, using boost containers is not as convient as expected. Especially when STL and boost are mixed.
So is here any plan to update boost's algorithm library/container library for a better exprience?

Potential memory leak?

clang-tidy on a project brought this to my attention:

/builds/ben.boeckel/smtk/build/../smtk/attribute/Attribute.cxx:234:3: note: Calling 'split<std::vector<std::__cxx11::basic_string<char>, std::allocator<std::__cxx11::basic_string<char> > >, const std::__cxx11::basic_string<char> &, boost::algorithm::detail::is_any_ofF<char>>'
  boost::split(tree, path, boost::is_any_of(seps));
  ^
/root/misc/root/smtk-deps/include/boost/algorithm/string/split.hpp:161:17: note: Calling 'token_finder<boost::algorithm::detail::is_any_ofF<char>>'
                ::boost::algorithm::token_finder( Pred, eCompress ) );         
                ^
/root/misc/root/smtk-deps/include/boost/algorithm/string/finder.hpp:219:55: note: Calling copy constructor for 'is_any_ofF<char>'
            return detail::token_finderF<PredicateT>( Pred, eCompress );
                                                      ^
/root/misc/root/smtk-deps/include/boost/algorithm/string/detail/classification.hpp:114:21: note: Taking false branch
                    if(use_fixed_storage(m_Size))
                    ^
/root/misc/root/smtk-deps/include/boost/algorithm/string/detail/classification.hpp:123:44: note: Memory is allocated
                        m_Storage.m_dynSet=new set_value_type[m_Size];
                                           ^
/root/misc/root/smtk-deps/include/boost/algorithm/string/finder.hpp:219:55: note: Returning from copy constructor for 'is_any_ofF<char>'
            return detail::token_finderF<PredicateT>( Pred, eCompress );
                                                      ^
/root/misc/root/smtk-deps/include/boost/algorithm/string/finder.hpp:219:55: note: Calling '~is_any_ofF'
/root/misc/root/smtk-deps/include/boost/algorithm/string/detail/classification.hpp:135:51: note: Left side of '&&' is false
                    if(!use_fixed_storage(m_Size) && m_Storage.m_dynSet!=0)
                                                  ^
/root/misc/root/smtk-deps/include/boost/algorithm/string/detail/classification.hpp:139:17: note: Potential memory leak
                }
                ^

There is apparently some way to assign to m_Storage.m_dynSet while not freeing it on the way out. I suspect some kind of condition mismatch. Or is this a false-positive?

boost::algorithm::split_regex hangs and consumes CPU on dangling alternatives

I happened to typo a regex, and I noticed that boost::algorithm::split_regex started consuming a bunch of CPU. I don't know is this would have eventually caught itself and terminating. The regex in question was ;|, and this appears to be true for any dangling |.

I'm a bit surprised that boost::regex allowed ;| as valid, given split_regex's behavior.

Simple example up at https://gist.github.com/directionless/c38eb7dc216bcd93b40c3ecaf99f326e

I tested this on darwin with boost 1.67, and on linux with boost 1.65

(This was moved here from boostorg/regex#76)

Lack of bidimensional for_each

I think it would be nice to have a way to easily apply a binary operation to two zipped ranges (or maybe a Nary operation to n zipped ranges).
It would be kind of boost::accumulate but returning void and that would not accumulate along the container dimension.
Example:
https://godbolt.org/z/gWFvcn

variadic min/max/minmax

Hello,
for min/max/minmax with multiple parameters there are only functions per std::initializer_list:
https://en.cppreference.com/w/cpp/algorithm/min
https://en.cppreference.com/w/cpp/algorithm/max
https://en.cppreference.com/w/cpp/algorithm/minmax
The parameters are always passed by value and not by reference and the result is also a value. This is a problem with types like std::array, std::string, etc.

Since the compare class cannot be the last function parameter in a variadic implementation (as in the std implementations) another position must be found, possibilities:

first function parameter: 2 implementations would be needed each, once with compare class and once without. I don't find that useful.
first template parameter: only one implementation is needed with default template parameter(s).

A simple variadic implementation could look like this:
minmax_variadic.hpp.txt

minmax needs 2 compare classes (each for min and max) - this is more flexible.

thx
Gero

std::upper_bound with iterator hint?

In this PR, I use std::upper_bound to calculate the empirical cumulative distribution function. However, the principle use of this function is in a quadrature, where each call to the function occurs with increasing argument. Hence, if I could cache an iterator hint, then the call complexity would be an amortized log(log(N)) (or is it amortized constant time? I forget. In either case, it's better than log(N).)

Does boost.algorithm have iterator hints for binary searches?

Several cxx algorithm headers are not self-sufficient/self-contained

The following program (with boost as being part of the include path) doesn't compile:

#include <boost/algorithm/cxx14/equal.hpp>
int main() {}

and produces (depending on the compiler) a diagnostics like:

In file included from prog.cc:2:
/opt/wandbox/boost-1.70.0/clang-head/include/boost/algorithm/cxx14/equal.hpp:23:9: error: unknown type name 'BOOST_CONSTEXPR'
        BOOST_CONSTEXPR bool operator () ( const T1& v1, const T2& v2 ) const { return v1 == v2 ;}
        ^
/opt/wandbox/boost-1.70.0/clang-head/include/boost/algorithm/cxx14/equal.hpp:27:5: error: unknown type name 'BOOST_CXX14_CONSTEXPR'
    BOOST_CXX14_CONSTEXPR
    ^
/opt/wandbox/boost-1.70.0/clang-head/include/boost/algorithm/cxx14/equal.hpp:44:5: error: unknown type name 'BOOST_CXX14_CONSTEXPR'
    BOOST_CXX14_CONSTEXPR
    ^
/opt/wandbox/boost-1.70.0/clang-head/include/boost/algorithm/cxx14/equal.hpp:68:1: error: unknown type name 'BOOST_CXX14_CONSTEXPR'
BOOST_CXX14_CONSTEXPR
^
/opt/wandbox/boost-1.70.0/clang-head/include/boost/algorithm/cxx14/equal.hpp:87:1: error: unknown type name 'BOOST_CXX14_CONSTEXPR'
BOOST_CXX14_CONSTEXPR
^
5 errors generated.

The header "boost/algorithm/cxx14/equal.hpp" misses to include "boost/config.hpp".

The following lists the headers that I found are obviously affected by a missing

#include <boost/config.hpp>

"boost/algorithm/cxx11/copy_n.hpp"
"boost/algorithm/cxx14/equal.hpp"

Several algorithms not mentioned on the front page of docs

Several algorithms provided by the library aren't mentioned on the front page of the docs and hence are likely to go unnoticed by many users.

I'm happy to submit a PR for this. Please shout if I should do that.

Doc request: indicate constexpr support for algorithms

Hi,
I believe most if not all of the algorithms in boost are constexpr if the compiler supports it and C++14 or greater is used. (yes?)

That's not indicated in the docs, as far as I can tell. I recently implemented a couple myself because I assumed the boost ones were not, from the docs; and at the time I didn't go look in the source code to see that they actually were. (yeah, I was being an idiot)

search example should be updated

all search examples in https://github.com/boostorg/algorithm/blob/develop/example/search_example.cpp
should be updated with
ba::boyer_moore_search ( haystack.begin (), haystack.end (), needle1.begin (), needle1.end ()) != std::make_pair(haystack.end(), haystack.end()) instead of haystack.end() alone.

Automated formatting

Would there be any interest in introducing a .clang-format file for this library? It would not set precedent for boost - gil, graph, histogram, multiprecision, nowide, outcome, and yap all currently have .clang-format files. As far as I can tell, those are each unique format files, so I think there would be large latitude to use any configuration that makes sense for this library.

new implementation for string split

Hello So I have been working on string split and wrote my own and its faster than boost implementation of split

source code

I was hoping to contribute the same in boost 😄

Enable and enhance CI

Travis and Appveyor files were added 5 months ago, but CI was never enabled for this repository.
Add codecov.io, cppcheck, covscan, ubsan, and valgrind targets to improve quality.

Modular Boost C++ Libraries Request

We are in the process of making B2 build changes to all of the B2 build files
to support "modular" consumption of the Boost Libraries by users. See this list
post for some details: https://lists.boost.org/Archives/boost/2024/01/255704.php

The process requires making a variety of changes to make each Boost library
independent of the super-project structure. But the changes do not remove the
super-project structure or the comprehensive Boost release. The changes make
solely make it possible, optionally, for users, like package manages, to easily
consume libraries individually.

Generally the changes include:

Adding a libroot/build.jam.
Porting any functionality from libroot/jamfile to libroot/build.jam.
Moving boost-install declaration from libroot/build/jamfile is applicable.
Adjusting other B2 build files in the library, like test/jamfile, as needed.
Possible changes to C++ source files to remove includes relative to the
super-project boostroot location.

Some examples of such changes:

We are asking how you would like us to handle the changes. We would prefer if
you allow the owners of the Boost.org GitHub project to make changes to B2
build files, as needed, to accomplish the changes. But understand
that you may want to manage the proposed changes yourself.

We previously sent emails to all known maintainers to fill out a form with their
preference. We are contacting you in this issue as we have not gotten a response
to that email. You can see the ongoing responses for that form and the responses
to these issues here https://github.com/users/grafikrobot/projects/1/views/6

We are now asking if you can reply directly to this issue to indicate your
preference of handling the changes. Please supply a response to this question
and close the issue (so that we can verify you are a maintainer).

How would you like the build changes to be processed?

Pull request, reviewed and merged by a BOOSTORG OWNER.
Pull request, reviewed and merged by YOU.
Other. (please specify details in the reply)

Also please indicate any special instructions you want us to consider. Or other
information you want us to be aware of.

Thanks you, René

algorithm/string -- find_all_regex() gives a compiler error when the result container is vector<iterator_range<string::iterator>>

The doc says that the container we should pass to this function can be std::vector<boost::iterator_rangestd::string::iterator>. But when I run the program it gives a compile error. But when the result container passed, is a std::vectorstd::string, everything works fine.

First code snippet is using std::vector<boost::iterator_rangestd::string::iterator> as the result.

#include "boost/algorithm/string/split.hpp"
#include "boost/range/iterator_range_core.hpp"
#include <iostream>
#include <boost/algorithm/string.hpp>
#include <boost/algorithm/string/regex.hpp>
#include <vector>

int main(int, char**) {
    
    std::string s("Hello world");
    boost::regex regex("\\w");

    std::vector<boost::iterator_range<std::string::iterator>> result;
    boost::find_all_regex(result, s, regex);

}

Following is the last 3 lines of the compiler error. The whole error is too long.

c:\mingw\include\c++\9.2.0\bits\stl_iterator.h:787:11: note: no known conversion for argument 1 from '__gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string >' to 'const __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string >&'

c:\mingw\include\c++\9.2.0\bits\stl_iterator.h:787:11: note: candidate: 'constexpr __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string >::__normal_iterator(__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string >&&)'

c:\mingw\include\c++\9.2.0\bits\stl_iterator.h:787:11: note: no known conversion for argument 1 from '__gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string >' to '__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string >&&'

Also I ran the same program in Clang compiler too. Still the same result.

But when I run the following program with the container as std::vectorstd::string everything works without a hitch.

#include "boost/algorithm/string/split.hpp"
#include "boost/range/iterator_range_core.hpp"
#include <iostream>
#include <boost/algorithm/string.hpp>
#include <boost/algorithm/string/regex.hpp>
#include <string>
#include <vector>

int main(int, char**) {
    
    std::string s("Hello world");
    boost::regex regex("\\w");

    std::vector<std::string> result;
    boost::find_all_regex(result, s, regex);

}

Feature Request: Any plan to add trim support for string_view?

Nowadays string_view is used more widely, so I think it's a helpful API, I suggest adding it.

Unexpected behavior when using algorithm::trim() to remove spaces

The issue comes from boostorg/compute#817 where boost::trim() is invoked to sanitize OpenCL kernel arguments from preprocessor-generated strings. One of the failing cases taken directly from the boost compute repo is this:

two, pi          // original string   
[two, pi]        // vector after split() using comma as delimiter
two              // first element after trim()
 p               // second element after trim()

Here the trim() actually leave a leading space left of pi and slices one valid character on the right. One big BUT: this only happens to Linux cross-compiler targeting Android platform, downloaded from Android NDK page. Where as MSVC on Windows, GCC/Clang on Mac all run without problems. What might be the reason of this unexpected behavior?

`replace_all` in VC++ 7.1 doesn't work from 1.55 onwards in some circumstances.

Example code below, errors below that. Hopefully this isn't user error, I'm trying to upgrade some existing code, but I am stuck with this compiler.

The code compiles up to and including 1.55, and, if I uncomment the commented parts of the code, it will compile again from 1.58 onwards.

Compile command: cl.exe test.cpp /Fo"test.obj" /GR /MD /Gy /W3 /EHsc /Gd /Gm- /arch:SSE2 /Zm200 /I"Microsoft Visual C++ Toolkit 2003/include" /nologo /Z7 /O2 /Oy /Oi /G7 /c /I"boost_1_55_0"

Code

#include <boost/algorithm/string.hpp>

void test()
{
	//typedef boost::range_iterator<std::string, void>::type itr;

	//itr begin, end;
	//typedef boost::iterator_range< boost::range_iterator<std::string, void>::type > result_type;

	//result_type range(begin, end);

	std::string vec, search, format;
	boost::replace_all(vec, search, format);
}

Output from 1.72

test.cpp
boost_1_72_0\boost\range\mutable_iterator.hpp(37) : error C2146: syntax error : missing ';' before identifier 'type'
        boost_1_72_0\boost\range\mutable_iterator.hpp(43) : see reference to class template instantiation 'boost::range_detail::extract_iterator<C>' being compiled
        with
        [
            C=boost::remove_reference<boost::range_iterator<std::string,void>::type>::type
        ]
        boost_1_72_0\boost\range\mutable_iterator.hpp(72) : see reference to class template instantiation 'boost::range_detail::range_mutable_iterator<C>' being compiled
        with
        [
            C=boost::remove_reference<boost::range_iterator<std::string,void>::type>::type
        ]
        boost_1_72_0\boost\range\has_range_iterator.hpp(27) : see reference to class template instantiation 'boost::range_mutable_iterator<C,Enabler>' being compiled
        with
        [
            C=boost::remove_reference<boost::range_iterator<std::string,void>::type>::type,
            Enabler=void
        ]
        boost_1_72_0\boost\range\has_range_iterator.hpp(27) : see reference to class template instantiation 'boost::range_detail::has_type_impl_<T>' being compiled
        with
        [
            T=boost::range_mutable_iterator<boost::remove_reference<boost::range_iterator<std::string,void>::type>::type,void>
        ]
        boost_1_72_0\boost\mpl\eval_if.hpp(41) : see reference to class template instantiation 'boost::range_detail::has_type<T,fallback_>' being compiled
        with
        [
            T=boost::range_mutable_iterator<boost::remove_reference<boost::range_iterator<std::string,void>::type>::type,void>,
            fallback_=boost::mpl::bool_<false>
        ]
        boost_1_72_0\boost\range\has_range_iterator.hpp(73) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
        with
        [
            C=boost::is_const<boost::remove_reference<boost::range_iterator<std::string,void>::type>::type>,
            F1=boost::range_detail::has_type<boost::range_const_iterator<boost::remove_reference<boost::range_iterator<std::string,void>::type>::type,void>,boost::mpl::bool_<false>>,
            F2=boost::range_detail::has_type<boost::range_mutable_iterator<boost::remove_reference<boost::range_iterator<std::string,void>::type>::type,void>,boost::mpl::bool_<false>>
        ]
        boost_1_72_0\boost\range\has_range_iterator.hpp(73) : see reference to class template instantiation 'boost::range_detail::has_range_iterator_impl<T>' being compiled
        with
        [
            T=boost::remove_reference<boost::range_iterator<std::string,void>::type>::type
        ]
        boost_1_72_0\boost\mpl\if.hpp(63) : see reference to class template instantiation 'boost::has_range_iterator<T>' being compiled
        with
        [
            T=boost::range_iterator<std::string,void>::type
        ]
        boost_1_72_0\boost\mpl\eval_if.hpp(40) : see reference to class template instantiation 'boost::mpl::if_<T1,T2,T3>' being compiled
        with
        [
            T1=boost::has_range_iterator<boost::range_iterator<std::string,void>::type>,
            T2=boost::range_iterator<boost::range_iterator<std::string,void>::type>,
            T3=boost::mpl::identity<void>
        ]
        boost_1_72_0\boost\range\iterator_range_core.hpp(452) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
        with
        [
            C=boost::has_range_iterator<boost::range_iterator<std::string,void>::type>,
            F1=boost::range_iterator<boost::range_iterator<std::string,void>::type>,
            F2=boost::mpl::identity<void>
        ]
        boost_1_72_0\boost\mpl\aux_\preprocessed\plain\and.hpp(25) : see reference to class template instantiation 'boost::iterator_range<IteratorT>::is_compatible_range_<Source>' being compiled
        with
        [
            IteratorT=boost::range_iterator<std::string,void>::type,
            Source=boost::range_iterator<std::string,void>::type
        ]
        boost_1_72_0\boost\mpl\aux_\preprocessed\plain\and.hpp(55) : see reference to class template instantiation 'boost::mpl::aux::and_impl<C_,T1,T2,T3,T4>' being compiled
        with
        [
            C_=true,
            T1=boost::iterator_range<boost::range_iterator<std::string,void>::type>::is_compatible_range_<boost::range_iterator<std::string,void>::type>,
            T2=boost::mpl::true_,
            T3=boost::mpl::true_,
            T4=boost::mpl::true_
        ]
        boost_1_72_0\boost\range\iterator_range_core.hpp(469) : see reference to class template instantiation 'boost::mpl::and_<T1,T2>' being compiled
        with
        [
            T1=boost::mpl::not_<boost::is_convertible<boost::range_iterator<boost::iterator_range<boost::range_iterator<std::string,void>::type>>::type,boost::iterator_range_detail::iterator_range_base<boost::range_iterator<std::string,void>::type,boost::iterators::incrementable_traversal_tag>::iterator>>,
            T2=boost::iterator_range<boost::range_iterator<std::string,void>::type>::is_compatible_range_<boost::range_iterator<std::string,void>::type>
        ]
        boost_1_72_0\boost\core\enable_if.hpp(41) : see reference to class template instantiation 'boost::iterator_range<IteratorT>::is_compatible_range<Source>' being compiled
        with
        [
            IteratorT=boost::range_iterator<std::string,void>::type,
            Source=boost::range_iterator<std::string,void>::type
        ]
        boost_1_72_0\boost\algorithm\string\detail\finder.hpp(68) : see reference to class template instantiation 'boost::enable_if<Cond,T>' being compiled
        with
        [
            Cond=boost::iterator_range<boost::range_iterator<std::string,void>::type>::is_compatible_range<boost::range_iterator<std::string,void>::type>,
            T=void
        ]
        boost_1_72_0\boost\algorithm\string\find_format.hpp(272) : see reference to function template instantiation 'boost::iterator_range<IteratorT> boost::algorithm::detail::first_finderF<SearchIteratorT,PredicateT>::operator ()<boost::range_iterator<C,Enabler>::type>(ForwardIteratorT,ForwardIteratorT) const' being compiled
        with
        [
            IteratorT=boost::range_iterator<std::string,void>::type,
            SearchIteratorT=std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator,
            PredicateT=boost::algorithm::is_equal,
            C=std::string,
            Enabler=void,
            ForwardIteratorT=boost::range_iterator<std::string,void>::type
        ]
        boost_1_72_0\boost\algorithm\string\replace.hpp(655) : see reference to function template instantiation 'void boost::algorithm::find_format_all<SequenceT,boost::algorithm::detail::first_finderF<SearchIteratorT,PredicateT>,boost::algorithm::detail::const_formatF<RangeT>>(SequenceT &,FinderT,FormatterT)' being compiled
        with
        [
            SequenceT=std::string,
            SearchIteratorT=std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator,
            PredicateT=boost::algorithm::is_equal,
            RangeT=boost::iterator_range<boost::algorithm::detail::first_finderF<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator,boost::algorithm::is_equal>::search_iterator_type>,
            FinderT=boost::algorithm::detail::first_finderF<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator,boost::algorithm::is_equal>,
            FormatterT=boost::algorithm::detail::const_formatF<boost::iterator_range<boost::algorithm::detail::first_finderF<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator,boost::algorithm::is_equal>::search_iterator_type>>
        ]
        C:/Users\billw\Documents\GitHub\Caveman2Cosmos\boost_test\test.cpp(13) : see reference to function template instantiation 'void boost::algorithm::replace_all<std::string,std::string,std::string>(SequenceT &,const Range1T &,const Range2T &)' being compiled
        with
        [
            SequenceT=std::string,
            Range1T=std::string,
            Range2T=std::string
        ]
boost_1_72_0\boost\range\mutable_iterator.hpp(37) : error C3254: 'boost::range_detail::extract_iterator<C>' : class contains explicit override '__ctor' but does not derive from an interface that contains the function declaration
        with
        [
            C=boost::remove_reference<boost::range_iterator<std::string,void>::type>::type
        ]
boost_1_72_0\boost\range\mutable_iterator.hpp(37) : error C2838: '__ctor' : illegal qualified name in member declaration
boost_1_72_0\boost\range\mutable_iterator.hpp(37) : error C2461: 'boost::range_detail::extract_iterator<C>' : constructor syntax missing formal parameters
        with
        [
            C=boost::remove_reference<boost::range_iterator<std::string,void>::type>::type
        ]
boost_1_72_0\boost\range\mutable_iterator.hpp(37) : error C2501: 'boost::range_detail::extract_iterator<C>::type' : missing storage-class or type specifiers
        with
        [
            C=boost::remove_reference<boost::range_iterator<std::string,void>::type>::type
        ]

boost::algorithm::trim_copy() does not remove \b character

I was testing the functionality of boost::algorithm::trim_copy() API and noticed that when running boost::algorithm::trim_copy(std::string(" \t\r\n\b ")), the result did not remove the \b character. Is this a bug in the function's implementation? The documentation states that it should remove all leading and trailing whitespace characters, but it seems to be missing the backspace character. Can this issue be investigated and resolved? Thank you.

BOOST_AUTO_TEST_CASE(testTrim) {
BOOST_CHECK_EQUAL(FOO, boost::algorithm::trim_copy(FOO + " "));
BOOST_CHECK_EQUAL(FOO, boost::algorithm::trim_copy(" " + FOO + " "));
BOOST_CHECK_EQUAL(FOO, boost::algorithm::trim_copy(" " + FOO));
BOOST_CHECK_EQUAL(FOO, boost::algorithm::trim_copy(FOO + ""));
// BOOST_CHECK_EQUAL("", boost::algorithm::trim_copy(std::string(" \t\r\n ")));
// \b
BOOST_CHECK_EQUAL("", boost::algorithm::trim_copy(std::string(" \t\r\n\b ")));
}

Enhance CI

Add codecov.io, cppcheck, covscan, ubsan, and valgrind targets to improve quality.

Docs for is_sorted erroneously state that it defaults to std::less_equal

_{^{Following on from Trac#13383…}}

Docs for is_sorted() currently say:

If no comparison predicate is specified, then std::less_equal is used (i.e, the test is to see if the sequence is non-decreasing)

…but that's not true—it defaults to std::less—see line 60 of boost/algorithm/cxx11/is_sorted.hpp.

This code confirms the default behaviour matches std::less not std::less_equal.

int main () {
  std::vector<int> a        = { 1, 2, 2, 3 };

  std::cerr << "default   : " << std::boolalpha << boost::algorithm::is_sorted( a                      ) << "\n";
  std::cerr << "less      : " << std::boolalpha << boost::algorithm::is_sorted( a, std::less      <>{} ) << "\n";
  std::cerr << "less_equal: " << std::boolalpha << boost::algorithm::is_sorted( a, std::less_equal<>{} ) << "\n";
}

I vote: change the docs, not the code, because the code matches std::. I'm happy to submit a PR for this - please shout if I should do that.

The apply_permutation algorithm requires C++11

The apply_permutation algorithm requires C++11. Is this intended ?

If so, should the apply_permutation test only run when the compiler is at the C++11 or higher level ?
If not so, should apply_permutation be changed to use Boost type traits rather than standard type traits, and will it work that way ?

fast variadic string-concat

Hello,
often string functions of the form
str = str + concat(strings...)
or
str = concat(strings...)
are needed. But so far there is no variadic std::concat or boost::algorithm::concat. I would like to make up for that here.
The goal of course must be to limit memory operations to the most necessary, i.e. to avoid temporary strings and thus (superfluous) new/delete etc.
My current implementations concat.hpp.txt
This also works with very old compilers - of course C++11 is generally required https://godbolt.org/z/cvWrzxr1e