I am confused when should I add the trailing _t to typedef'ed types?
For example, should I do this:
typedef struct image image_t;
or this:
typedef struct image image;
What are the general rules?
Another example, should I do this:
typdef enum { ARRAY_CLOSED, ARRAY_OPEN, ARRAY_HALFOPEN } array_type_t;
or this:
typdef enum { ARRAY_CLOSED, ARRAY_OPEN, ARRAY_HALFOPEN } array_type;
Please enlighten me.
Thanks, Boda Cydo.
In POSIX, names ending with _t are reserved, so if you are targeting a POSIX system (e.g., Linux), you should not end your types with _t.
_t; and it targets POSIX systems, and is the base printing system for modern Macs. –
Quintuplicate _t suffix. –
Daphnedaphnis _t suffix. –
Bollworm _t suffix is reserved and should not be used for user-defined types. –
Evildoer _t anywhere" to "no-one else may use _t". Unless there's a document that specifically reserves _t for POSIX use, I think this table has been misinterpreted. –
Bollworm _t anywhere" means that they can define macros with _t, which means any of your uses of _t are subject to macro substitution. –
Barbule I personally despise the _t convention. So long as you are consistent, it really does not matter, however.
Note that (as other answers here indicate) if you are coding to some other standard, such as POSIX, you need to check if it's okay in that standard before using such names.
When should use use _t? Never? It's reserved by a major standard (POSIX) and even if it's not now, your code might someday be used in a POSIX environment, so using _t is a bad idea.
I would go further to say that over-use of typedef is bad in general. If your type is a struct, union, or enum, use these keywords when you declare variables and it makes your code more clear. Use of typedef is best reserved for when you want to make the underlying type invisible for abstraction/encapsulation purposes. A few great examples from standard C are size_t, int32_t, mbstate_t, and the stdio FILE.
Some of the worst abuses of typedef are by the Windows API (WORD, DWORD, INT, LPSTR etc.) and glib (gint, gchar, etc.). Making duplicates of the standard C types with the same intended usage is only confusing and serves to lock developers into your library/platform by polluting all the code with these nonstandard type names.
typedefs, you can easily use int instead of gint (of, of course, for your non-exotic platform, they are the same). –
Michaeu gint is not defined as any particular size of integer; it's just as arbitrary as int. If the glib API functions need a particular size then they should just use that type: for example int32_t if they need 32bit integers or size_t if they need an object size or array index, etc. –
Franny _t. POSIX reserves absolutely any name ending in _t for potential future use. In C++ it's probably a non-issue as long as you use the headers that isolate the standard types to a namespace... –
Franny int, bool, const char *, etc., whenever possible. Types such as qreal are used when required to solve some problem (Qt manual on qreal: "Typedef for double on all platforms except for those using CPUs with ARM architectures. On ARM-based platforms, qreal is a typedef for float for performance reasons"). –
Cannula _t prefix, rather, it discourages using it (Relevant text: "all conforming applications are required to avoid symbols ending in ‘‘_t’’"). library_name_sub_module_type_name_t cannot be reasonably compared to err_t or struct state regarding namespace pollution. –
Arria _t suffixed typedefs all over the place and compile it into a valid, well defined POSIX-compliant program. To complement, one could NOT typedef any of the reserved keywords/typedefs and expect it to be POSIX-compliant in any way or form. –
Arria fopen can be expected to return a file in binary mode, even when "b" is not given). If this were not the case, then there would be no reason to make your code conformant in the first place (other than the fact that you can now label your source conformant), because then these guarentees that the program behaves as expected would be gone. –
Arria I use suffixes to increase readability: _t for typedef, and _e for enums since 25/30 years ... sometimes I use _st when typedef defines a struct.
I think that is good practice to get the code be readable and standardized, then I find right to use suffixes! Furthermore, to date, I have not found any POSIX official document stating that the suffix _t is reserved.
Old stdio.h contains _t ... See: grep -i "_t;" stdio.h :) I think POSIX standard is "a little" younger then C!
I am using _t suffix for enums and primitive types to distinguish them from variables. I put them into namespaces, so I don't care about _t reservations.
To justify it. Very often variable name is an allusion to typedefed type. Like std::size_t size;, array_t array etc. I have found that it's easier to pick up decent name for a variable, when type contains _t suffix. It also reminds me that it's a typedefed primitive and not some other beast like class for example.
size_t size_t = 0; is legal in C - it declares a variable named size_t of the type size_t. The conflict doesn't matter between types and variables. –
Roving size size = 0;. –
Retroflexion Pick good names for your types, just like you should with your variables, functions and anything else. A good name doesn't have redundant information embedded in it that makes it harder to read the code -- _t never helps you if you have a good name to begin with.
By the way: typedef image image; doesn't make any sense, since it just makes image a typedef to itself.
typedef struct image image which is useful in C. In C++, struct image variables may be declared image x; but in C, you have to declare them struct image x; so C programmers use the above to simplify struct declaration for commonly used types. –
Roving typedef image image — he wrote typedef struct image image. It's common in C. –
Woodwaxen © 2022 - 2024 — McMap. All rights reserved.
_tare reserved by some standard (not sure which). Though whatever you do, don't do_type_t. Pick_typeor_t(or something else), but please don't stack them. That's just silly. – Roving_tare reserved in POSIX: opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html. Not that I pay much attention to that (I typedef to names ending in_tpretty often). – Translocation_tfor types defined in ANY header. – Bollworm