なぜ誰もが標準のC型よりもtypedefなのですか？
Qt を使用する場合は、quint8、quint16などを使用する必要があります。
GLibを使用する場合は、guint8、guint16などを歓迎する必要があります。 。
Linux では、u32、s16などがあります。
uC/OSはSINT32、UINT16などを定義します。
そして、それらを組み合わせて使用する必要がある場合は、トラブルに備えておく必要があります。あなたのマシンではu32はtypedefd over longになり、quint32はtypedefd over intとコンパイラ文句を言う。
<stdint.h>がある場合、なぜ誰もがこれを行うのですか？これは図書館のある種の伝統ですか？
stdint.hは、これらのライブラリが開発されていた頃には存在していませんでした。そのため、各ライブラリは独自のtypedefsを作成しました。
古いライブラリの場合、問題のヘッダー（stdint.h）存在しませんでした。
ただし、まだ問題があります。これらのタイプ（uint64_tおよびその他）は、標準ではオプション機能です。したがって、準拠する実装はそれらに同梱されない可能性があります。したがって、現在ではライブラリにそれらを含めることを強制しています。
stdint.hは1999年以来標準化されています。多くのアプリケーションは、基礎となるマシンアーキテクチャからの部分的な独立性を維持するために型を定義します（事実上エイリアス）。
開発者は、アプリケーションで使用される型が、言語標準またはコンパイラー実装のいずれとも一致しない可能性のある動作に関するプロジェクト固有の仮定に一致するという自信を開発者に提供します。
このプラクティスは、オブジェクト指向の Façade デザインパターンに反映されており、インポートされたすべてのライブラリのラッパークラスを常に作成する開発者に酷使されています。
コンパイラの標準がはるかに低く、マシンのアーキテクチャが16ビットと異なる場合、 18-bit から 6-bit ワード長のメインフレームでは、これはかなり考慮事項でした。 32ビットARM組み込みシステムに収束している世界では、このプラクティスはあまり重要ではありません。 odd メモリマップを備えたローエンドマイクロコントローラーの懸念事項として残っています。
つまり、intにcharをtypedefする力があります
1つの「コーディングの恐怖」では、ある会社のヘッダーにはプログラマーがブール値を必要とするポイントがあり、charはジョブの論理的なネイティブタイプであると言及されたため、typedef bool char。その後、誰かが整数が最も論理的な選択であるとわかり、typedef bool int。結果は、Unicodeよりも前の年齢で、事実上typedef char int。
かなり前向きな、前方互換性があると思います。