これは簡単な質問のように思えますが、スタック オーバーフローの検索や Google で検索しても見つかりません。タイプの後に_t
平均が続くとは何ですか? そのような
int_t anInt;
ハードウェアを密接に扱うことを意図した C コードでよく見かけますが、それらが関連していると思わずにはいられません。
これは簡単な質問のように思えますが、スタック オーバーフローの検索や Google で検索しても見つかりません。タイプの後に_t
平均が続くとは何ですか? そのような
int_t anInt;
ハードウェアを密接に扱うことを意図した C コードでよく見かけますが、それらが関連していると思わずにはいられません。
Douglas Mayle が指摘したように、これは基本的に型名を示します。_t
したがって、変数名または関数名を ' ' で終わらせることは、混乱を招く可能性があるため、お勧めできません。と同様size_t
に、C89 標準ではwchar_t
、off_t
、ptrdiff_t
、およびおそらく私が忘れた他のいくつかが定義されています。C99 標準では、、、、、、などの追加の型が多数定義さuintptr_t
れています。これらの新しい型は で正式に定義されていますが、ほとんどの場合、which (標準 C ヘッダーでは通常ではありません) includesを使用します。( )およびで使用するマクロも定義します。intmax_t
int8_t
uint_least16_t
uint_fast32_t
<stdint.h>
<inttypes.h>
<stdint.h>
<inttypes.h>
printf()
scanf()
Matt Curtis が指摘したように、サフィックスにはコンパイラにとって意味はありません。それは人間志向の慣習です。
ただし、 POSIX_t
では ' ' で終わる追加の型名が多数定義されており、実装用に接尾辞が予約されていることにも注意してください。つまり、POSIX 関連のシステムで作業している場合、規則に従って独自の型名を定義することはお勧めできません。私が取り組んでいるシステムはそれを (20 年以上) 行ってきました。私たちは、定義したのと同じ名前の型を定義するシステムに定期的につまずきます。
これは、データ型の命名に使用される規則です。たとえば、typedef
次のようになります。
typedef struct {
char* model;
int year;
...
} car_t;
は_t
通常、不透明な型定義をラップします。
GCCは、標準 C および POSIX (GNU C ライブラリ マニュアル)_t
の将来のバージョンとの競合を避けるために、使用できない予約済みの名前空間にで終わる名前を追加するだけです。いくつかの調査の後、私は最終的に POSIX 標準 1003.1 内の正しい参照を見つけました: B.2.12 データ型(巻:理論的根拠、付録:システム インターフェイスの B. 理論的根拠、章: B.2 一般情報):
B.2.12 データ型
定義
された型 このセクションで定義された追加の型が「_t」で終わるという要件は、名前空間の汚染の問題によって促されました。プログラムの名前空間にシンボルを追加せずに、あるヘッダー ファイルで型 (POSIX.1-2017 で定義された型ではない型) を定義し、それを別のヘッダー ファイルで使用することは困難です。実装者が独自の型を提供できるようにするために、準拠するすべてのアプリケーションは、「_t」で終わる記号を避ける必要があります。これにより、実装者は追加の型を提供できます。型の主な用途は、POSIX.1-2017 で定義された構造体に追加できる (そして多くの場合、そうしなければならない) 構造体メンバーの定義にあるため、追加の型の必要性は切実です。
簡単に言えば、標準は、標準型のリストを拡張する可能性が高いと述べているため、標準は_t
独自の使用のために名前空間を制限しています。
たとえば、プログラムがPOSIX 1003.1 Issue 7に一致し、 type を定義したとしますfoo_t
。POSIX 1003.1 Issue 8は最終的に、新たに定義された type と共にリリースされfoo_t
ます。プログラムが新しいバージョンと一致していないため、問題が発生している可能性があります。使用を制限すると_t
、コードをリファクタリングできなくなります。したがって、POSIX への準拠を目指す場合は_t
、標準に記載されているように絶対に避ける必要があります。
補足: 個人的には、POSIX に固執するようにしています。なぜなら、POSIX はきれいなプログラミングの基本を提供すると思うからです。さらに、私はLinux Coding Style (第 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
サイズタイプです。
「タイプ」を意味する単なる慣例です。コンパイラにとって特別なことではありません。
主題についてのいくつかの良い説明がありました。タイプを再定義する別の理由を追加するだけです:
多くの組み込みプロジェクトでは、指定されたサイズを型に正しく記述し、異なるプラットフォーム (ハードウェア型コンパイラなど) 間の移植性を向上させるために、すべての型が再定義されます。
もう 1 つの理由は、異なる 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 によって定義されていることを意味します。