末尾の_t
をtypedef
'edタイプにいつ追加する必要があるのか混乱していますか?
たとえば、これを行う必要があります:
typedef struct image image_t;
またはこれ:
typedef struct image image;
一般的なルールは何ですか?
別の例、これを行う必要があります:
typdef enum { ARRAY_CLOSED, ARRAY_OPEN, ARRAY_HALFOPEN } array_type_t;
またはこれ:
typdef enum { ARRAY_CLOSED, ARRAY_OPEN, ARRAY_HALFOPEN } array_type;
教えてください。
ありがとう、BodaCydo。
POSIXでは、_t
で終わる名前が予約されているため、POSIXシステム(Linuxなど)をターゲットにしている場合は、タイプを_t
で終わらせないでください。
私は個人的に_t
の慣習を軽蔑しています。ただし、一貫性がある限り、それは実際には問題ではありません。
(ここでの他の回答が示すように)POSIXなどの他の標準にコーディングしている場合は、そのような名前を使用する前に、その標準で問題がないかどうかを確認する必要があることに注意してください。
いつ使用する必要があります_t
?決して?これは主要な標準(POSIX)によって予約されており、現在ではない場合でも、コードはいつかPOSIX環境で使用される可能性があるため、_t
を使用することはお勧めできません。
さらに言えば、typedef
の使いすぎは一般的に悪いことです。タイプがstruct
、union
、またはenum
の場合、変数を宣言するときにこれらのキーワードを使用すると、コードがより明確になります。 typedef
の使用は、抽象化/カプセル化の目的で基になる型を非表示にしたい場合に最適です。標準Cのいくつかの優れた例は、size_t
、int32_t
、mbstate_t
、およびstdio FILE
です。
typedef
の最悪の悪用のいくつかは、Windows API(Word
、DWORD
、INT
、LPSTR
など)とglibによるものです。 (gint
、gchar
など)。同じ使用目的で標準のC型を複製することは混乱を招くだけであり、これらの非標準の型名ですべてのコードを汚染することにより、開発者をライブラリ/プラットフォームに固定するのに役立ちます。
読みやすさを向上させるために接尾辞を使用します。typedefの場合は_t、25/30年以降の列挙型の場合は_eです... typedefが構造体を定義するときに_stを使用することがあります。
コードを読みやすく標準化するのは良い習慣だと思います。そうすれば、サフィックスを使用する権利が見つかります。さらに、これまで、接尾辞_tが予約されていることを示すPOSIX公式文書は見つかりませんでした。
古いstdio.hには_tが含まれています...参照:grep -i "_t;" stdio.h :) POSIX標準はCよりも「少し」若いと思います!
列挙型とプリミティブ型に_t
接尾辞を使用して、変数と区別しています。それらを名前空間に入れたので、_t
の予約は気にしません。
それを正当化するために。多くの場合、変数名はtypedefed型をほのめかします。 std::size_t size;
、array_t array
などのように、タイプに_t
サフィックスが含まれていると、変数の適切な名前を簡単に取得できることがわかりました。また、それはtypedefedプリミティブであり、たとえばクラスのような他の獣ではないことを思い出させます。
変数や関数などと同じように、型に適した名前を選択してください。良い名前には、コードを読みにくくする冗長な情報が埋め込まれていません。最初から良い名前がある場合、_tは役に立ちません。
ところで: typedef image image;
は、画像をそれ自体のtypedefにするだけなので、意味がありません。