_t（下線-t）が後に続くタイプは何を表しますか？

これは簡単な質問のようですが、スタックオーバーフロー検索やGoogleでは見つかりません。タイプの後に_t意味とは何ですか？といった

int_t anInt;

ハードウェアと密接に対応することを目的としたCコードで多く見られます。それらは関連していると思わずにはいられません。

Douglas Mayleが述べたように、それは基本的に型名を示します。その結果、_t混乱を招く可能性があるため、変数名または関数名を ' 'で終了することはお勧めできません。同様にsize_t、C89標準の定義wchar_t、off_t、ptrdiff_t、と私は忘れてしまった、おそらくいくつかの他。C99標準の定義のような余分な種類の、たくさんのuintptr_t、intmax_t、int8_t、uint_least16_t、uint_fast32_t、など。これらの新しい型はで正式に定義されて<stdint.h>いますが、ほとんどの場合<inttypes.h>、（通常は標準のCヘッダーに）が含まれて<stdint.h>いるものを使用します。また、（<inttypes.h>）は、printf()およびで使用するマクロを定義しますscanf()。

Matt Curtisが述べたように、接尾辞のコンパイラには意味がありません。それは人間指向の慣習です。

ただし、POSIXは ' _t'で終わる多くの追加の型名を定義し、実装用のサフィックスを予約することにも注意する必要があります。つまり、POSIX関連のシステムで作業している場合は、独自の型名を規則で定義することはお勧めできません。私が取り組んでいるシステムはそれを（20年以上）行ってきました。定義したのと同じ名前のタイプを定義するシステムに定期的につまずかれます。

これは、データ型の命名に使用される規則typedefです。

typedef struct {
  char* model;
  int year;
...
} car_t;

_t通常は不透明な型定義をラップします。

GCC _tは、Standard CおよびPOSIX （GNU Cライブラリマニュアル）の将来のバージョンとの競合を避けるために、使用できない可能性がある予約済みの名前空間に終わる名前を追加するだけです。いくつかの調査の後、私はついにPOSIX標準（1003.1、根拠（参考））内に正しい参照を見つけました：

B.2.12データ型

このセクションで定義されている追加の型が '' _t ''で終わるという要件は、名前空間の汚染の問題によって促されました。1つのヘッダーファイルでタイプ（IEEE Std 1003.1-2001で定義されていないタイプ）を定義し、プログラムの名前空間にシンボルを追加せずに別のヘッダーファイルで使用することは困難です。実装者が独自の型を提供できるようにするには、準拠するすべてのアプリケーションで、記号が '' _t ''で終了しないようにする必要があります。これにより、実装者は追加の型を提供できます。型の主な用途は、IEEE Std 1003.1-2001で定義されている構造に追加できる（多くの場合は必須）構造体メンバーの定義にあるため、追加の型の必要性は説得力があります。

一言で言えば、規格は規格タイプのリストを拡張する可能性が高いと述べているため、規格_tはそれ自体の使用のために名前空間を制限します。

たとえば、プログラムがPOSIX 1003.1第6号と一致し、タイプを定義したとしますfoo_t。POSIX 1003.1第7号は、新しく定義されたタイプで最終的にリリースされfoo_tます。プログラムが新しいバージョンと一致しないため、問題が発生する可能性があります。_t使用を制限すると、コードをリファクタリングできなくなります。したがって、POSIX準拠を目指す場合は_t、規格に明記されているように、必ずを回避する必要があります。

補足：個人的には、POSIXに固執しようとします。クリーンなプログラミングのための良い基礎を与えると思うからです。さらに、私はLinuxコーディングスタイル（第5章）ガイドラインをかなり気に入っています。typedefを使用しない理由はいくつかあります。この助けを願っています！

これは、通常typedefによって定義されるデータ型の標準の命名規則です。ハードウェアレジスタを扱う多くのCコードは、符号付きおよび符号なしの固定サイズデータ型にC99定義の標準名を使用しています。慣例として、これらの名前は標準ヘッダーファイル（stdint.h）にあり、_tで終わります。

それは「タイプ」を意味する単なる慣習です。コンパイラにとって特別な意味はありません。

に_tは、本質的に特別な意味はありません。しかし_t、typedefにサフィックスを追加することは一般的な使用に陥っています。

変数の命名に関するCの一般的な慣例に慣れているかもしれません...これは、ポインターの前にapを​​付け、グローバル変数の前にアンダースコアを使用するのが一般的である方法に似ています（これは少し一般的ではありません） 、および変数名を使用するにはi、jと、k一時的なループ変数のため。

ワードサイズと順序が重要なコードでは、BYTE WORD（通常は16ビット）DWORD（32 ビット）などの明示的なカスタム定義型を使用するのが非常に一般的です。

int_tの定義はintプラットフォーム間で異なるため、あまり良くありません- intどちらに準拠していますか？（ただし、最近では、ほとんどのPC中心の開発では32ビットとして扱いますが、PC以外の開発では、intを16ビットとして扱います）。

タイプを意味します。 size_tサイズタイプです。

主題についていくつかの良い説明がありました。タイプを再定義する別の理由を追加するだけです。

多くの組み込みプロジェクトでは、すべてのタイプが再定義されて、タイプに対する特定のサイズが正しく示され、さまざまなプラットフォーム（つまり、ハードウェアタイプコンパイラ）間の移植性が向上します。

別の理由は、さまざまなOS間でコードを移植可能にし、コードに統合しているOSの既存の型との衝突を回避するためです。このため、通常は一意の（可能な限り）接頭辞が追加されます。

例：

typedef unsigned long dc_uint32_t;

ハードウェアインターフェイスコードを扱っている場合は、調べているコードの作成者がint_t特定のサイズの整数であると定義している可能性があります。C標準は、int型に特定のサイズを割り当てません（コンパイラとターゲットプラットフォームに依存する可能性があります）int_t。特定の型を使用すると、移植性の問題を回避できます。

これは、ハードウェアインターフェイスコードの特に重要な考慮事項です。そのため、そこでの規則に最初に気付いたのかもしれません。

たとえば、C99では、/ usr / include / stdint.h：

typedef unsigned char           uint8_t;
typedef unsigned short int      uint16_t;
#ifndef __uint32_t_defined
typedef unsigned int            uint32_t;
# define __uint32_t_defined
#endif
#if __WORDSIZE == 64
typedef unsigned long int       uint64_t;
#else
__extension__
typedef unsigned long long int  uint64_t;
#endif

_t 常にtypedefによって定義されることを意味します。