refactor: use std::vector instead of bespoke Array class

[ckerr]

Part one of a three-part series to use std:: tools instead of bespoke ones. Part three will fix #6.

• Part 1: refactor: use std::vector instead of bespoke Array class #7
• Part 2: refactor: use std::min(), std::max() instead of bespoke #12
• Part 3: refactor: use std::unordered_map instead of bespoke utpHashTable #13

Unfortunately there don't seem to be any real tests for libutp, so the need to manually test is even greater than usual.

[ckerr]

@tearfur also requesting review from you since you've been so active in the C++ code lately, but GitHub doesn't give me that option in the Reviewers list.

Possibly it only shows people who have been previously active in the repo 🤔 Along that same rationale, I'm not sure if @'ing you here will show up in your notifications. I guess if you don't pong here I'll ping you in another PR instead 😸

[mikedld]

Unfortunately there don't seem to be any real tests for libutp, so the need to manually test is even greater than usual.

If we're forking it for good, might make sense to pull bittorrent#127 so that we're not completely blind here.

[ckerr]

might make sense to pull bittorrent#127 so that we're not completely blind here

Agreed. @mikedld Can you copy libutp/pull/127 into a PR in this repo?

If we're forking it for good

The last upstream commit was six years ago; but even so, forking isn't my first choice.

Looks like the last maintainer comment in a PR was in 2019; however, it was by @arvidn who is still very active on libtorrent, so maybe there's hope. Arvid, do you have any thoughts on landing PRs in https://github.com/bittorrent/libutp?

@mikedld IMO even if we fork we should keep changes compatible w/upstream and try to upstream them, e.g. PRs like bittorrent#132 or this one, e.g. housekeeping & small fixes, not big changes or protocol changes.

[mikedld]

It's already there in post-3.4-transmission branch, although uses CMake and not platform-specific build configs. Anyway, #8 is the slightly updated version of the upstream PR.

[mikedld]

If it's not the fork-fork yet, did you mean to target post-3.4-transmission with this PR then? Otherwise, should probably merge post-3.4-transmission changes into master...

[ckerr]

@mikedld, agreed. I've updated the branch to target post-3.4-transmission

[mikedld]

@ckerr, CI seems to be unhappy with C++ standard now, need to adjust the default in

libutp/CMakeLists.txt

Line 27 in 8bdf5e8

set(CMAKE_CXX_STANDARD 98)

[tearfur]

@ckerr @mikedld ping

[mikedld]

I'm fine with it, was under the impression that @ckerr is waiting out for something or maybe doing some more testing.

[ckerr]

I guess I've been holding back on this PR because it really belongs upstream.

As mentioned above, there are a couple of followups to this. I hope all of them make it upstream someday -- I'm not going to make any big breaking changes.