4 ms·
It’s better than dealing with needlessly long type names like uint32_t though
by circuit10 3y ago
It’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.