Replace boost string algorithms with their abseil counterparts

[asl]

Some refactoring and cleanup while there:

• Code moved from headers down to cpp
• StringRef replaced with std::string_view (header is not removed as I do not know how this might affect downstream)

[vlstill]

Thank you for cleaning away the StringRef. Could you also put [[deprecated(...)]] on the StringRef struct so the downstream tools are kind reminded to upgrade and we have a path to drop it completely some time in future? I think that would make sense :-).

On a more general note: is there a strong reason to replace boost algos with their abseil counterparts? It abseil significantly better? Is it easier to use? Do we strive to get rid of boost altogether? Since we have abseil for other reasons, I am not against this, but for example in case of the substitutions the boost syntax had some advantages (named paceholders).

[vlstill]

At the very least, we can probably put the implementation in .cpp. But this seems like maybe it is there only to simplify debugging with gdb.

[asl]

On a more general note: is there a strong reason to replace boost algos with their abseil counterparts? It abseil significantly better? Is it easier to use? Do we strive to get rid of boost altogether? Since we have abseil for other reasons, I am not against this, but for example in case of the substitutions the boost syntax had some advantages (named paceholders).

I like abseil string algorithms more. For example StrSplit could return a vector of string_view's, essentially skipping the copies of string pieces. It also returns vector by value, boost::split takes output by reference.

[fruffy]

On a more general note: is there a strong reason to replace boost algos with their abseil counterparts? It abseil significantly better? Is it easier to use? Do we strive to get rid of boost altogether? Since we have abseil for other reasons, I am not against this, but for example in case of the substitutions the boost syntax had some advantages (named paceholders).

My personal opinion is that it is nice to keep our dependencies simple. Since we are basically forced to use Abseil with Protobuf we might as well make use of it. Since we do not want to keep two utility frameworks around we should slowly deprecated widespread usage of boost. Another reason I am in favor of slowly phasing out boost is that is generally a huge framework and unlike Abseil including one boost header can pull in many others. We do not need to get rid of it entirely but should be judicious of what we include. #3898 is an attempt to simplify things a little.

[asl]

My personal opinion is that it is nice to keep our dependencies simple. Since we are basically forced to use Abseil with Protobuf we might as well make use of it. Since we do not want to keep two utility frameworks around we should slowly deprecated widespread usage of boost. Another reason I am in favor of slowly phasing out boost is that is generally a huge framework and unlike Abseil including one boost header can pull in many others. We do not need to get rid of it entirely but should be judicious of what we include. #3898 is an attempt to simplify things a little.

I think after this PR we'll end with:

• few containers here and there, that could be replaced with some header-only implementation dropped to lib.
• boost::graph for graph backend
• boost::multiprecision
• boost::random
• boost::format

The latter could be replaced by fmt or Abseil's format routines, or we can wait for next standard bump. It's just huge pile of work :)

boost::random is used for Mersenne-Twister – need to double check if these days normal standard library is mature enough to instantiate rng with bigint type.

[vlstill]

boost::random is used for Mersenne-Twister – need to double check if these days normal standard library is mature enough to instantiate rng with bigint type.

It seems it is not :-/

UIntType -- The result type generated by the generator. The effect is undefined if this is not one of unsigned short, unsigned int, unsigned long, or unsigned long long. (https://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine)

[vlstill]

This looks good to me.

[asl]

@fruffy Will you please take a look when you have a chance? Thanks!

[fruffy]

@fruffy Will you please take a look when you have a chance? Thanks!

Will try to give a look tomorrow, things have been a bit busy lately..

[asl]

Will try to give a look tomorrow, things have been a bit busy lately..

Sure, no worries! Just wanted to clear my patch queue a bit :)