Just some janitorial work. Also made some slight consistency adjustments such as in crypto_test.cpp.
Edit: apparently can't edit files in the leveldb subtree, also my test system didn't build zeromq so i didn't catch my syntax error.
Just some janitorial work. Also made some slight consistency adjustments such as in crypto_test.cpp.
Edit: apparently can't edit files in the leveldb subtree, also my test system didn't build zeromq so i didn't catch my syntax error.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
NACK, I think this makes code less readable. Usually we argue about auto usage in new code, but I don't recall of changing code to use auto.
My preference is to use auto like auto x = new Foo so it's clear the x type.
66 | @@ -67,12 +67,12 @@ double CAddrInfo::GetChance(int64_t nNow) const 67 | 68 | CAddrInfo* CAddrMan::Find(const CNetAddr& addr, int* pnId) 69 | { 70 | - std::map<CNetAddr, int>::iterator it = mapAddr.find(addr); 71 | + auto it = mapAddr.find(addr);
I'd rater see this changed to std::map<CNetAddr, int>::const_iterator it = ... for instance.
The following scripted-diff compiles if someone wants to look for ::const_iterator candidates:
git grep -lE '::iterator ' "*.cpp" "*.h" | \
grep -vE '(crypto_tests.cpp|coins_tests.cpp|limitedmap.h|guiutil.cpp|addrman.cpp|bloom.cpp|net.cpp|net_processing.cpp|coins.cpp|coins.h)' | \
xargs sed -i 's/::iterator /::const_iterator /g'
NACK.
From the pull request template:
Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected.
Edit: if you're looking for ways to contribute, I recommend checking out the good first issue tag.
CI builds for this patch took 2X-3X longer than builds for contemporary patches, and one of them failed due to timeout (I don't know how that CI build succeeded thereafter).
@jeffersoncarpenter CI time varies and depends on current build cache. Sometimes failure builds are restarted manually by people with the required permissions.
However, after the above comments, I think you should close this and follow @jamesob advice or @practicalswift #15762 (review) suggestion.
Closing.