3 ms·
If there's one thing I would do to C it is to replace the normal datatypes with u8, u16, u32, u64 (ad infinitum) and their signed brethren s8, s16, s32, s64, ..
by emilfihlman 9y ago
If there's one thing I would do to C it is to replace the normal datatypes with u8, u16, u32, u64 (ad infinitum) and their signed brethren s8, s16, s32, s64, ...
And don't start with the stupid (u)intXX_t.
- kurtisc 9y agoYou could just use macros or typedefs for the the (u)intXX_t types.
- breadbox 9y agoAnd therein lies the issue. Everyone does just that, causing needless clashes. If you're writing a library, you can either switch back to the standard type names in your external header file, or you include the typedefs/macros there as well. The former choice ruins some of the point of having these types, and might even mask cross-platform issues. The latter runs the risk of clashing with the user's owns typedefs, or with another library writer's typedefs. (And god help you if exactly one library writer chose to do it via macros.)
- Nursie 9y agoThey aren't stupid, and they are both standard and available on nearly every system going. People absolutely should use stdint. h I wish more would.
- Ace17 9y ago> People absolutely should use stdint.h Definitely. However, you have to admit the names (uint32_t) could be made less verbose, like "u32".
- emilfihlman 9y agoExactly. We are talking about the smallest possible datatypes that build up everything here. They don't have to be named variable_typeFactory_type_signed_t.
- emilfihlman 9y agoYou are missing the point. The question was about if I could change something in C. I use stdint.h (and inttypes.h since fuck printf without it amirite) but u8 ... are just better.
- bdamm 9y agouint8_t is really not very hard to type. Personally I would much prefer uint16_t over u16. Confusion over type handling is a source of some of the worst bugs. Remember, uint16 isn't the same as 16 bits if you consider endian-ness.