As a Windows C++ dev, I’d love to see a win64 API declared which updates to sizeof(int)=sizeof(void*), unsigned char, utf8 only (using new codepage), straight API declarations in one header per Windows DLL with no macro hackery.
-
-
Replying to @TimSweeneyEpic
I think using the C int type isn't best practice these days. Use int32_t, or int64_t, or intptr_t, or an easier-to-type typedef of those. Otherwise
1 reply 0 retweets 3 likes -
Replying to @ThaLobsta
There is a nice world in which int is sufficient for indexing any array that can exist. This is the only low-level definition of int that makes sense. This size_t garbage litters code with all kinds of shady conversions and other accidents-waiting-to-happen.
3 replies 0 retweets 8 likes -
Replying to @TimSweeneyEpic @ThaLobsta
The C++ standards committee apparently agrees with you that size_t was a mistake, in particular its unsignedness (which I presume is the source of most conversion issues). https://github.com/Microsoft/GSL has gsl::index which is signed. Sadly too late to fix the STL I guess.
2 replies 0 retweets 2 likes -
Replying to @wvo @ThaLobsta
I’d love to see a one time breaking change that fixes all of this stuff both in the ISO standard and in platform defaults. So much of this stuff is just dumb.
1 reply 0 retweets 1 like -
For example, the integer comparison operators should always compare the actual values correctly. Big innovation there!
1 reply 0 retweets 2 likes -
Replying to @TimSweeneyEpic @wvo
An interesting way to do this would be to add "unsigned" arithmetic instructions that work modulo 2^31 or 2^63 instead of 2^32 or 2^64. Then, your unsigned types can be defined as strict subsets of the signed types. And while you're at it, add trap-on-overflow instructions...
1 reply 0 retweets 1 like -
Replying to @ThaLobsta @TimSweeneyEpic
Except there's a ton of data in this world that is already using the full 32/64 bits, so these 31/63 bit types would run into trouble quickly. The #1 use of unsigned types is to be precise about bits. WASM gets it right: signedness should be part of the operation, not the type.
1 reply 0 retweets 1 like -
Replying to @wvo @ThaLobsta
Yes for arithmetic operations that wrap or modulo, but no for comparisons! Signed and unsigned types precisely describe the subsets of the integers they represent, so comparison of signed and unsigned values always has a precise mathematical meaning.
1 reply 0 retweets 1 like -
Replying to @TimSweeneyEpic @ThaLobsta
Yes, that's why WASM has separate operations for signed/unsigned comparison:https://github.com/WebAssembly/design/blob/master/Semantics.md#32-bit-integer-operators …
2 replies 0 retweets 0 likes
Sure, but C++ compilers generate the wrong instruction sequence when comparing an unsigned integer to a signed integer. The C++ answer unnecessarily disagrees with mathematics, which is unequivocally a bad language design.
-
-
IEEE 754 states a core principle which no numeric library should violate for atomic operations: when the operands are rational numbers and the mathematical result is precisely representable in the target format, that's the result. For comparison, the target format is bool.
0 replies 1 retweet 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.