4 ms·
Longtime C, C++, and embedded programmer here. 1. Why "should" it be something different? It is semantically part of code flow; making it a pragma breaks that
by colanderman 4y ago
Longtime C, C++, and embedded programmer here.
1. Why "should" it be something different? It is semantically part of code flow; making it a pragma breaks that model. This replaces the nonstandard __builtin_unreachable().
2. This doesn't exist to save typing. static_cast<auto> doesn't make sense to me (that reads like a no-op). static_cast<underlying> introduces a new reserved word which is a big no-no.
3. This is not the same as htonl, which only does anything on little-endian machines. (htonl is also a POSIX function, not a C++ function.)
- lvass 4y ago1. Isn't std inadequate in "embedded" programming?
- tialaramex 4y agoIn principle the C++ standard does define a subset of its standard library which is available in Freestanding environments (ie without an operating system). In practice what is actually available and whether it works satisfactorily varies considerably more than for the hosted environments. Almost everything is up for grabs and so you probably can't rely on the standard much. Your compiler vendor probably couldn't care less what the standard says anyway.
- colanderman 4y agoDepends on what's you're targeting, but if you're coding for say, AVRs, you're not using C++, but rather C, in which case `unreachable` is your friend. [1] [1] https://en.cppreference.com/w/c/program/unreachable https://en.cppreference.com/w/c/program/unreachable
- pjmlp 4y agoIn some cases not even C, just a tiny subset full of chip vendor extensions.
- SubjectToChange 4y agoA lot of it, sure. But there are a lot of header only types which do not dynamically allocate memory on their own. For instance <algorithm>, <atomic>, <bitset>, <limits>, <iterator>, <type_traits>, etc.