actually, that's one of the domains I work in (hard real-time bare metal uC stuff). Although tooling/vendor support can be pretty bad once you get it running there are many advantages to C++. First of all, it can be more efficient than C because of constexpr and stricter aliasing
-
-
If the type exists, you don't need to reject it. But it would need to exist as a full-blown integer type in standards mode.
-
Lacking a good suffix for __int128, in my C compiler (mostly used for targeting my own experimental ISA designs) I just went with LLX / ULLX.
-
I did really have int128 literal support in clang for a while, under the bogus "Microsoft extension" suffix [u]i128 (which doesn't actually exist in any Microsoft compiler, but the parser was there). It's been removed though =/
-
There are likely all sorts of problems with doing it, like how it behaves in
#if... -
It worked great! The only major issue was the formal semantics issues around extended types and intmax, as you sketched out.
-
But preprocessor requires all arithmetic take place in a common signed or unsigned type matching [u]intmax_t...
-
As I said, the only real issue is around intmax.
-
Even without stdint.h and intmax_t, though, you'd run into the same problem with consistently defining what's supposed to happen at the preprocessor level...
- 12 more replies
New conversation -
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.



