make VERBOSE=1 check
Details
- Reviewers
deadalnix CCulianu zquestz - Group Reviewers
Restricted Owners Package (Owns No Changed Paths) Restricted Project - Commits
- rSTAGINGfdd499448849: Add Amount class and use it for CENT and COIN.
rABCfdd499448849: Add Amount class and use it for CENT and COIN.
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- shammah/camountnew
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 856 Build 856: arc lint + arc unit
Event Timeline
Added:
- Tests
- Several integral-specific overrides
- Integral-specific implicit constructor
Updating D529: Summary:
Add CAmountNewClass and use it for CENT and COIN.
Added some comments and a question..
src/amount.h | ||
---|---|---|
32 ↗ | (On Diff #1361) | Suggest: pass by reference eg const CAmountNew & in all of these. |
36 ↗ | (On Diff #1361) | Ditto... and ditto for all the operators below. |
79 ↗ | (On Diff #1361) | Question: Why are all of these friends and not just member functions? Any reason? |
src/amount.h | ||
---|---|---|
12 ↗ | (On Diff #1361) | You might also want to #include <type_traits> here for header paranoia. std::enable_if lives in <type_traits> and as it happens now it got pulled in for us -- but this is not guaranteed into the infinite future of C++ impl's.. so I would suggest explicitly including the <type_traits> header. |
src/amount.h | ||
---|---|---|
43 ↗ | (On Diff #1361) | Suggest: Implementing the real comparison only for operator< and operator== and then making operator >,<=, >=, != all be implemented in terms of those 2 basic operators. Eg: operator<=(lhs, rhs) { return !(lhs > rhs); } operator>=(lhs, rhs) { return !(lhs < rhs); } operator>(lhs, rhs) { return rhs < lhs; } operator!=(lhs, rhs) { return !(lhs == rhs); } |
79 ↗ | (On Diff #1361) | Nevermind: I see you want to take advantage of implicit conversion etc so yeah you need friend for these. |
src/amount.h | ||
---|---|---|
32 ↗ | (On Diff #1361) | I don't think it is really necessary. This clearly work as a value type better than as a reference type. Now, because C++ doesn't differentiate between the 2 but if you get it wrong you'll regret it dearly (see slicing for instance) it's probably a good idea to come up with some naming convention that distinguish the 2. I suggest ISomething for interfaces, CSomething for reference type kind of classes and no prefix for value types. We assume value type are cheap to copy and if they aren't, make them non copiable by default. Does that work ? If so, then this class should just be named Amount |
- Change operator implemntation to depend on < and == only.
- Add include for type_traits.
- Rename CAmountNew to Amount.
I'm not sure the division thing is what we want to do, but the overall thing looks solid.
src/amount.h | ||
---|---|---|
21 | Maybe that's not necessary. I'd rather have a compile time error than a value assigned to 0 when I forget to initialize it. | |
24 | I'm not sure why you need an enable_if here ? That seems a bit overkill. Why not just take a int64_t ? Other integral types will convert anyway. You also may want to declare this as explicit. | |
25 | You can take by value so it'll match rvalues as well. | |
75 | This will truncate and return a non monetary value. It doesn't looks correct to me. | |
81 | Same as for / | |
src/validation.cpp | ||
3808 | Looks like you are using clang-format 4.0+ . Please use 3.8 for now. | |
src/wallet/test/wallet_tests.cpp | ||
89 | Put the comment on the preceding line. | |
194 | dito | |
204 | dito |
src/amount.h | ||
---|---|---|
24 | Double was implicitly converting. I wanted to ensure that didn't happen. | |
25 | Tried it: ./amount.h:24:25: error: copy constructor must pass its first argument by reference Amount(const Amount _camount) : amount(_camount.amount) {} ^ const & | |
75 | This is intentional. I do not want it to return a monetary type. Division and Modulus are not defined on money. If they're occurring you shouldn't get a monetary type back. I can remove them altogether though and just use .GetSatoshis() where needed. |
src/amount.h | ||
---|---|---|
21 | Tried the other suggestion, see: https://stackoverflow.com/questions/38772637/overload-ambiguous-int-int64-t-vs-int-double | |
75 | Do you want these operations defined? |