GetNum(VarOrAddress, Offset = 0, SignedOrFloat? = 0, Size = 4) PutNum(Number, VarOrAddress, Offset = 0, Size = 4) ; Best parameter order?If the caller passes in a variable for VarOrAddress, that variable's address is used as the base. Otherwise, the value is assumed to be a numeric address. If you think about it, this is weird/inconsistent; but it helps user-friendliness (since caller doesn't need to use & or + operators) and it benchmarks 15% faster compared to passing something like "&var + 4". This also explains the Offset parameter (i.e. it's faster and more user-friendly).
The whole reason to support raw addresses instead of simply address-of-variables is flexibility: it seems conceivable the caller may have a raw address from somewhere but not know which variable it points into.
SignedOrFloat defaults to 0 (unsigned), but it can be 2 for floats or 1 (or any other value) for signed integers.
PutNum() could auto-detect floating point numbers by the presence of a decimal point. However, floats are so rarely used with PutNum() that auto-truncation-to-integer might be preferable, in which case an additional parameter could be added to specify "treat this as a floating point number".
Please let me know if you have any comments on the above, or can think of any improvements to: [*:1rfd01v0]Parameter ordering.
[*:1rfd01v0]PutNum's return value (if any). Maybe it should be Address+Offset+Size so that the caller can pass it to the next call to PutNum (i.e. for adjacent fields in a struct).
[*:1rfd01v0]Default mode is "unsigned" for GetNum. Unsigned seems more common than signed?
[*:1rfd01v0]Default size of 8 (double) for floating point numbers under the assumption that 64-bit (double) is more common than 32-bit (float).Edit: Added a new poll to choose among the ones that had the most votes in the previous poll.