<jpk68:matrix.org> I could be wrong, but it seems adopting utf8proc would also allow us to replace some homegrown canonicalization functions

<jpk68:matrix.org> For example, src/common/utf8.h. I think there are also some instances in epee

<rbrunner7> @jpk68:matrix.org: Pretty sure that's correct, that's some ugly "handmade" code that we could replace later on.

<thomasbuilds:matrix.org> is migrating off boost welcomed?

<thomasbuilds:matrix.org> I'm thinking to boost::string_ref -> std::string_view

<thomasbuilds:matrix.org> boost::optional → std::optional is probably the cleaner first step

<ofrnxmr:xmr.mx> what is the gain?

<thomasbuilds:matrix.org> Mostly modernization: std types, lighter includes, less version-bump churn... Real gain would be when a compiled boost lib is fully removed (chrono/thread/filesystem -> std) and drops off the link line

Funny how it's all subjective. Your "real gain" is a "mostly pointless change" for me. The only gain I see in what you just said is lighter includes, assuming the "lighter" is significant enough performance wise.

There is at least one thing where the use of boost instead of std is intended. I *think* it was a threading related type, and I *think* it was due to some bug in the STL shipping with GCC. Can't recall more than that.

(though I don't know what you mean by "less version-bump churn", that might be a plus too)

There have been new bugs introduced from "cleanup" patches before. It's not a theoretical danger.

<thomasbuilds:matrix.org> On less version-bump churn I meant boost occasionally deprecates/removes APIs between releases, so bumping the pinned version sometimes needs guards

<thomasbuilds:matrix.org> moneromooo: this? monero-project/monero #1721

Seems probable.

So we keep using boost because some GCC version didn't work properly with threads on mingw 9 years ago? Do I get it right?

For this type, yes.

(coupled with if it ain't broke, don't fix it)

Hi

selsta I've reviewed what looks to be the last of the pending review PRs for 0.18.5.1

ty

Hopefully we'll get it out soon because many P2Pool users just don't know how to update P2Pool separately from Monero-GUI

.merges

10597 10598 10646 10774 10790 10801

sech1: could you check 10646 again?

done

<rbrunner7> I have a method in a class with a template parameter, like this:

<rbrunner7> template<class str_type>

<rbrunner7> void data::encode(const language& lang, str_type& str) const

<rbrunner7> I wanted to only have these 2 lines in the .h file, and move the implementation to the .cpp file. The .h and the .cpp file compile, but later the linker complains about a missing method.

<rbrunner7> So that's not possible? I have to implement right in the .h file for the templating to work out right?

You can put specializations of this template into the cpp file, but if any specialization is missing you will get linker errors.

When the code is entirely in the header, compiler creates specializations automatically, and linker then finds them

If you just put the generic template code in cpp file, it will not be specialized (apart from the explicit specializations in that single cpp file)

so you'd have to do something like this in the cpp file: paste.debian.net/hidden/58f8e138

exact syntax might be a bit different

<rbrunner7> I see, thanks. Kind of defeats the whole purpose of templating somehow, if you have to give all the instantiations that you want to support yourself in the .cpp file ...

It doesn't, use still have one copy of the code, you just declare each specialization (without copying the code)

*you still have

<vtnerd> And we alter the stack size with boost thread. This isn't possible with std thread. I forget the platform where this was needed > <sech1> So we keep using boost because some GCC version didn't work properly with threads on mingw 9 years ago? Do I get it right?

<vtnerd> And asio isn't easily replaced, although there's a standalone version

asio is another story, not so easy to replace indeed

.merge+ 10798

Added