miklhh
commented
3 years ago Regarding what to do with arithmetic between signed and unsigned numbers, I'm currently thinking of disabling support of it completely, requiring users to explicitly convert one number to a common type before performing arithmetic. This would save some code writing and this is how the problem is solved in the VHDL language. We prefer to minimize implicit type conversion which would be necessary otherwise.
The only real reason I can think of why not to go down this path, is that C++ uses usual arithmetic conversion to implicitly convert signed numbers to unsigned when stumbling on an expression that requires such. Then again all compilers today will warn their users (with -Wall enabled) that binary arithmetic between signed and unsigned types are dangerous. So maybe we really should just disable it completely.
As of right now, the support for unsigned number has been put on hold while we try to figure out what to do with arithmetic between signed and unsigned numbers. To minimize code duplication, this library tries to implement generic arithmetic functions that can be used by both signed and unsigned numbers. Less code, less to maintain, easier to keep sane and functioning.
Before this issue can be considered resolved, especially make sure the following have been taken in consideration:
get_num_sign_extended()andset_num_sign_extended(), although this does not really make sense for an unsigned number. An idea for these functions is to just truncate any part that cannot be contained withing the numbers range.operator=) only. Make sure this the norm even in the unsigned variant of this implementation.