If I do a `typedef` in C or C++, when should I add `_t` at the end of typedef'ed type? [duplicate]

This question already has answers here: C++ type suffix _t, _type or none (4 answers) Closed 4 years ago.

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.

---

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.

---

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!

---

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.

---

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.