Replace loop patterns with std algorithms under libs/

[aledomu]

No description provided.

[keryell]

Nice modernization effort!

[keryell]

Suggested change

	std::list<timepos_t>::iterator i = std::find_if(
	auto i = std::find_if(

everywhere.

[aledomu]

Let me know if you think it's OK now for you.

[x42]

Personally I find this (std::copy_if, std::transform) syntax much less readable than loops. Just an auto loop would likely be easier to understand in most of those cases.

And as discussed on IRC, I still think the preferred solution is not to batch replace code, but modernize it when actually working on a function (for bug fixes, or adding features). That may also provide opportunity to refactor it completely, and test; rather than just blindly replace it.

[x42]

Changes to libs/vamp-plugins/ would need to go to https://github.com/c4dm/qm-vamp-plugins/tree/master/plugins/
Otherwise they will be lost when we copy the remote repo next time.

I still think batch updates are not the best way to move forward. There is no benefit to Ardour users, yet the slight risk of breaking things. Not all of modern C++ is suitable for a massive multi-threaded cross-platform realtime program (notably std::thread and std::chrono are a no-go, and other std APIs might have similar issues), not to mention quirks with various compilers (notably MSVC).

With your C++ knowledge, I can imagine that your time might spent better fixing some bugs or adding actual features, rather than doing effective NO-OP commits.

just my 2c.

[aledomu]

Personally I find this (std::copy_if, std::transform) syntax much less readable than loops. Just an auto loop would likely be easier to understand in most of those cases.

It brings more lines in many cases, but just reading the name of the algorithm function states what kind of loop it is and its meaning without having to read into its mechanics, which I have found useful when skimming through the code as a newcomer. However I understand that for anyone that is already familiar with the code and therefore only cares about the mechanics this may have the opposite effect. I myself don't even think this is ideal. The ranges API is far better IMO, but I realised later and it requires C++20/23 (something I don't advocate for now, the change to C++17 was already enough). Anyways, the verbosity of C++ can't be avoided for this functional style.

That said, I'm not completely against reverting specifically all the std::transform and std::copy_if.

I still think the preferred solution is not to batch replace code, but modernize it when actually working on a function (for bug fixes, or adding features). That may also provide opportunity to refactor it completely, and test; rather than just blindly replace it.

Sure, I won't start a similar effort under gtk2_ardour/. But this was already done as part of #949, which it was motivated by my (unsuccesful) attempt at dispensing with Boost for dealing with the change in container types more easily. Unless all of the final result is undesired, I prefer not to remove these code changes without previous evaluation.

Changes to libs/vamp-plugins/ would need to go to https://github.com/c4dm/qm-vamp-plugins/tree/master/plugins/. Otherwise they will be lost when we copy the remote repo next time.

Oops, reverted. BTW, shouldn't third-party libs be linked as a git submodule, instead of a plain copy of files?

[x42]

Oops, reverted. BTW, shouldn't third-party libs be linked as a git submodule, instead of a plain copy of files?

We do change the build-system, and we do not want to depend on any external hosts that we don't have control over (we've been bitten by that in the past). While we could mirror this repo on git.ardour.org and then use it as submodule, it is a lot more convenient to just run a script to copy the files. Besides we do in fact patch it: see https://github.com/Ardour/ardour/blob/master/tools/update_qm-vamp.sh#L33-L62 (because of MSVC).