6 ms·
Yeah but not for basic types. Also, most code mingles sooner or later with other code. Than this is just ugly.
by oaiey 3y ago
Yeah but not for basic types. Also, most code mingles sooner or later with other code. Than this is just ugly.
- circuit10 3y agoIt’s better than dealing with needlessly long type names like uint32_t though
- oaiey 3y agoNo. It would be better if the standardization groups would have done that, but not when every developer has a different scheme
- circuit10 3y agoIt’s not great but they’re just aliases so they’re interchangeable, which means you can keep everything consistent within a project and it won’t cause any problems when interacting with outside code
- lelanthran 3y agoUntil you include a header written by someone with the same opinion, and now you get compile errors because they both defined 'u8'. I gotta be honest, all of those style suggestions look good until you try them in a non-solo and non-isolated project, and then you see what a mess you created. We've all been there, as C programmers, and we've all done that in the past, which is why we don't do it anymore
- circuit10 3y agoUnless they were defined to completely different types, that shouldn’t be an error
- lelanthran 3y ago> Unless they were defined to completely different types, that shouldn’t be an error In this case it almost certainly will be - after all, the blog posts `byte` is defined as char, which could be signed or unsigned. A correct typedef for `byte` is `uint8_t`, so it's almost guaranteed that this will conflict. Which is why I said it's best not to redefine the primitive types - you're almost certain to conflict with someone else who defined it differently.
- uxp8u61q 3y agoLong type name?? uint32_t is literally 8 characters long. There's not much to cut here.
- billfruit 3y agouint32_t isn't that long, and is quite clear what type it means.
- Sharlin 3y agoRust made the correct choice: things used most often should be assigned the shortest names. This "Huffman encoding" style is what natural languages have evolved toward as well. In 2023, if I were to write C, and didn't have existing guidelines to adhere to, I'd most probably introduce the same typedefs as the author here has done.