私はGTK +でちょっとしたプロジェクトを少し作っています。GTKのデータ型とベースのデータ型
GLibのは、基本データ型のちょうどtypedef sは（gintは、intのtypedefであるようにvoid*及びためgpointer）であるようにgintgpointerと、同様に、データ型のシリーズを定義します。
今、GTKを決して使用しない関数やクラスがあるとします。私は本当に私はGTKヘッダーが含まれていなくてもクラス/関数を別の場所に再利用できるように基本データ型を使用するように誘惑されるだろう。
一方、コード内にgintとを混在させるのはかなり醜いことがわかります。実際には同じものです。要約すると
があるかどうかを疑問に思って浮動小数点、ロング、ショート、文字の代わりにバイトエイリアスなどの独自の型エイリアスが必要な第三者図書館
非常に迷惑です。これは移植性を確保するためにしばしば行われますが、各ライブラリに独自の標準を与えることになります。
ここで私が不快感を感じるのはカップリングの観点からです。私はレンダリングの問題から切り離されるべき一般的なメッシュインターフェースを持っているかもしれません。それでも、そのデータの一部は、OpenGL関数に直接渡されます。この関数は、渡される整数のサイズがsizeof(GLint)に一致すると仮定したいと考えています。
これは単なる審美的なものではありません。このメッシュヘッダーにGLヘッダーを含めることは、それを使用するサードパーティのプラグインライターにこのようなコンパイル時の依存関係を必要としないはずの、広く使用されているソフトウェア開発キットの一部である可能性もあります。
しかし、移植性が問題です。非常に大規模なレガシーCコードベースで悪夢のようなシナリオに耐えることができました。暗黙の前提がコードベース全体にわたって行われました。sizeof(int) == sizeof(void*)です。このコードベースを64ビットに移植するには、何年もかかっていました。
私が個人的に解決したことは、何年もかけて平易な古くなっていないデータ型を好むようになることです。私はまた、符号付き整数だけを使用することを好んだ。私はこれまで、コンテナを介して基本ループの警告を避けることさえ、含まれている要素の数を示すためにint、その他unsigned int、その他size_tなどを使用することは迷惑だった。少なくとも個人的には、私は保守時間を短縮しているのが、intを好むだけで、それほどうまくいきませんでした。 assert(sizeof(int) == sizeof(GLint));：sizeof(int) != sizeof(GLint)いくつかのプラットフォーム上での潜在的最悪のシナリオを軽減しようとする
は、例えば、私は自由にこれら二つが等しいという仮定を行うコードの周りにアサーションを振りかけるする傾向があります。これは、32ビットから64ビットに移植するときに直面した悪夢のシナリオに関連する痛みを大幅に緩和するはずです。また、これらの仮定を明示的に表現している。
これは私のケースで快適なバランスを確立するためにこれを見つけました。もちろんこれはすべて主観的なものであり、ユースケースに応じてかなり異なる場合があります。しかし、これは、これらのサードパーティ製のライブラリにもかかわらず、平易な古くなっていないデータ型をますます好むことができるかもしれない可能性のある解決策の1つで、あなたの前提が一部のプラットフォームで正しくなくなった場合、最悪の場合のシナリオに直面しません。
Havoc Penningtonがこの件に関してここでコメントしました：http://stackoverflow.com/questions/2800310/converting-an-array-of-characters-to-a-const-gchar/2800318#2800318 – ptomato