diff options
author | Wladimir J. van der Laan <laanwj@gmail.com> | 2019-01-21 20:12:19 +0100 |
---|---|---|
committer | Wladimir J. van der Laan <laanwj@gmail.com> | 2019-01-21 20:28:56 +0100 |
commit | f0c9e1c22b8a043983f3ba90ad910b67cf981e36 (patch) | |
tree | e2a126ad18a535c9219cde63d7b6e443ede53805 /src/banman.h | |
parent | 6e6b3b944d12a252a0fd9a1d68fec9843dd5b4f8 (diff) | |
parent | b301950df32443e358bc22ca22c6f9ac09d18219 (diff) |
Merge #14906: refactor: Make explicit CMutableTransaction -> CTransaction conversion.
b301950df32443e358bc22ca22c6f9ac09d18219 Made expicit constructor CTransaction(const CMutableTransaction &tx). (lucash-dev)
faf29dd019efef4b05e8e78885926764134d9c04 Minimal changes to comply with explicit CMutableTransaction -> CTranaction conversion. (lucash-dev)
Pull request description:
This PR is re-submission of #14156, which was automatically closed by github (glitch?)
Original description:
This PR makes explicit the now implicit conversion constructor `CTransaction(const CMutableTransaction&)` in `transaction.h`.
Minimal changes were made elsewhere to make the code compilable. I'll follow up with other PRs to address individually refactoring functions that should have a `CMutableTransaction` version, or where a `CTransaction` should be reused.
The rationale for this change is:
- Conversion constructors should not be explicit unless there's a strong reason for it (in the opinion of, for example, https://google.github.io/styleguide/cppguide.html, and https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ro-conversion. Let me know your take on this).
- This particular conversion is very costly -- it implies a serialization plus hash of the transaction.
- Even though `CTransaction` and `CMutableTransaction` represent the same data, they have very different use cases and performance properties.
- Making it explicit allows for easier reasoning of performance trade-offs.
- There has been previous performance issues caused by unneeded use of this implicit conversion.
- This PR creates a map for places to look for possible refactoring and performance gains (this benefit still holds if the PR is not merged).
Tree-SHA512: 2427462e7211b5ffc7299dae17339d27f8c43266e0895690fda49a83c72751bd2489d4471b3993075a18f3fef25d741243e5010b2f49aeef4a9688b30b6d0631
Diffstat (limited to 'src/banman.h')
0 files changed, 0 insertions, 0 deletions