3 ms·
I think we're getting to the point where C++ users should define two classes: class Integer { // uses unsigned integers for all operations
by xscott 3y ago
I think we're getting to the point where C++ users should define two classes:
class Integer {
// uses unsigned integers for all operations
// but converts to signed when you need output
};
class Pointer {
// uses void* and memcpy for all loads or stores
};
Put all of the correct operator overloading on those to get the ergonomics we had in the 90s.
Then we can safely ignore all the undefined behavior which has been so eagerly embraced by the compiler writers, and we can go back to treating the hardware as though it is sane. (Which the hardware is desperately trying to fake being anyways)
After that, we can create some sane container types which don't offer up dangling references or pointers, and Bob's your uncle.
- celrod 3y agoIf my signed integers overflow, that is wrong. I want to be able to detect if it ever happens, not have that be defined as perfectly valid wrapping behavior. If it's undefined, it's perfectly legal for the compiler to make overflow trap, so I can catch it, or confirm it never happens when running tests our debugging. `-ftrapv` or ``-fsanitize=undefined` do this.
- xscott 3y agoTo each their own. I want my 64 bit integers to do what the CPU does, and I could bore you with useful examples where two's complement wrap around is exactly the right behavior. But more importantly, I don't ever want to worry about stumbling into undefined behavior, and compiler extensions like -ftrapv or -fwrapv are not part of the standard. I can't count on those being there when I switch compilers, and if I write a library for others, I can't count on the application developer using the flags I need.