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;")
I 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.
From 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.
Probably 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.
Mixing CamelCase type names and snake_case variable names feels chaotic to me, but it’s the standard coding style for Python, Ruby, Rust, and Google’s C++ code. I wonder who used it before Python.
Where 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.
For 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.
It'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).
I'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.
Recently 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.
