3 ms·
What are people's thoughts on using "_t" as a suffix for types in C/C++, as this source does? My understanding is that it is technically reserved for language d
by hoten 3y ago
What are people's thoughts on using "_t" as a suffix for types in C/C++, as this source does? My understanding is that it is technically reserved for language defined types, but I haven't come across a reasonable alternative (and having no suffix makes for odd code, for example a custom type for a "viewport" is better imo as "viewport_t viewport;" than "viewport viewport;")
- genocidicbunny 3y agoProbably not everyone's cup of tea, but I tend to use CamelCase for types, and under_scores for variables. It does result in constructs like 'Viewport viewport;' but at least it's easy enough to tell that Viewport is the type.
- djbusby 3y agoI've seen that suffix on loads of C stuff from ages ago. All stuff that circa 90s codes (some older)
- uxp100 3y agoI don’t believe that’s a c language thing, but a posix thing. anyway, in my own code for myself I do it, but it is frequently forbidden in coding standards I’ve worked under (even in a non posix environment) and it doesn’t rise to the level of pushing back on it usually, I’ll name types however the style guide wants, even if it’s worse. t prefix, worse. The whole word typedef, worse.
- cxr 3y agoRecently I was musing to myself about adopting the convention `func_r`, to denote "the thing that the function `func` returns". Why spend the energy trying to think up two names (one for the function you're writing and one for what you should call the type of its result)? It's also amenable to preprocessor macros, if you're so inclined.
- OnACoffeeBreak 3y agoWhere I work the style guidelines for C specify to use "_type". Interestingly enough, the huge code base for embedded products with a custom OS does not rely on <stdint.h> types for fixed-width integer types: "uint32_t", for example. Instead, a company-wide header defines "uint32" etc. without the "_t" suffix. I don't know what guided that decision.
- flohofwoe 3y agoFor a very long time the fixed-width types in stdint.h were not universally available, or in other headers, especially Visual Studio trailed behind. I guess this problem has stuck even after all C compilers caught up with C99.
- andrewmcwatters 3y agoYou're not supposed to do it, but anyone who works with the Quake family of engines is used to it, so when in Rome...
- bentcorner 3y agoIt's useful when you have an IDE that doesn't help you very much and you need to know what a thing is just from what code is in front of you.
- LexiMax 3y agoFrom what I understand, it's POSIX that reserves the _t suffix, not C. That being said, I picked up the _s/_t habit from working on idtech codebases, and decided that I'm fine with my own C codebases forever having a "not POSIX compliant" stamp on it, whatever that means in practice. For C++ I just use InitialCamelCase.
- badsectoracula 3y agoI've being using it for a long time and the only time i had a problem was when i ported an old 3d game engine of mine to Mac OS X and i had a type "key_t" which conflicted with some Mac header. I just used the preprocessor to #define key_t mykey_t (or something like that) after the Mac-specific headers in the couple of files where the conflict was and never thought about it again.
- snvzz 3y agoI use and prefer capitalization for typedefs. Cube instead of cube_t.
- flohofwoe 3y agoIt's totally fine and legal. Only POSIX reserves the _t for types, but POSIX is not the C standard (but even when writing code for POSIX, it's not like POSIX changes much these days, so unexpected type collisions because of POSIX updates will be very unlikely).