構造体にtypedefを使用する理由

C（ANSI、C99など）では、構造体は独自の名前空間に存在します。リンクリストの構造体は、次のようになります。

struct my_buffer_type {
   struct my_buffer_type * next;
   struct my_buffer_type * prev;
   void * data;
};

しかし、ほとんどのCプログラマーが次のような構造体を自動的にtypdefすることは非常に自然に思えます

typedef struct tag_buffer_type {
   struct tag_buffer_type * next;
   struct tag_buffer_type * prev;
   void * data;
} my_buffer_type;

そして、通常の型のように構造体を参照しget_next_element(my_buffer_type * ptr)ます。

今、私の質問は次のとおりです。これには特定の理由がありますか？

ウィキペディアによると、http：//en.wikipedia.org/wiki/Typedef#Usage_concerns

一部の人々は、typedefの広範な使用に反対しています。ほとんどの引数は、typedefが変数の実際のデータ型を単純に隠すという考えに基づいています。たとえば、LinuxカーネルハッカーでありドキュメンタリーであるGreg Kroah-Hartmanは、関数プロトタイプ宣言以外の目的での使用を推奨していません。彼は、この慣行はコードを不必要に難読化するだけでなく、プログラマーが単純に大きなタイプの構造であると誤って誤用する可能性もあると主張します。[4]

typedefを使用すると、コードの保守が簡単になると主張する人もいます。K＆Rは、typedefを使用する2つの理由があると述べています。まず、プログラムの移植性を高める手段を提供します。プログラムのソースファイル全体に現れるすべてのタイプを変更する代わりに、変更する必要があるtypedefステートメントは1つだけです。第二に、typedefは複雑な宣言を理解しやすくします。

場合によってはstructtypedefされた構造体を使用しない別の名前空間を使用することで十分なメリットがないのか、他にもCプログラミング文化がいくつかあるので（Windows CプログラミングにはLinux Cプログラミングとは異なる伝統があります）私が知らない伝統。

それから私は歴史的な考察に興味があります（前任者、Cの最初のバージョン）。

typedefされた構造体を広範囲に使用する大規模なプロジェクトに取り組みました。いくつかの理由でそうしました。これはC99以前および名前空間の分離であったことに注意してください。

1. のmy_buffer_type *buffer代わりに入力する方が簡単struct tag_buffer_type *bufferで、コードベースのサイズ（1M + loc）が大きな違いをもたらしました。

2. 構造をオブジェクトに抽象化します。構造体内の個々の変数すべてに焦点を当てるのではなく、それが表すデータオブジェクトに焦点を合わせます。この抽象化により、一般にコードがより便利で簡単に記述できるようになりました。

   • これは、あなたが提供したGreg Kroah-Hartmanに起因する引用とは直接矛盾していると思います。FWIW、そのプロジェクトはクライアント/サーバーアプリケーションであり、カーネルではなかったので、考慮すべきいくつかの異なる考慮事項があることは間違いありません。

3. 構造をオブジェクトとして扱うことで、情報をより適切にカプセル化することもできました。コードレビューは、新しい開発者が私たちが導入したカプセル化の原則に違反するという非常に多くの状況を捉えました。typedefされた構造体を使用すると、これらの違反が明らかになりました。

4. サーバーを備えた半ダースのプラットフォームと、クライアントを備えたかなり多くのプラットフォーム向けに書いたように、移植性は懸念事項でした。

毎回入力する代わりに

struct my_buffer_type *buffer;

あなたはtypedefそれを直接使用することができます

my_buffer_type *buffer;

typedefの主な用途は、コードの記述と可読性の向上に必要なキーストロークの数を減らすことです。