igraph の作成者の 1 人として、これがプロジェクトの最初に下された疑わしい設計上の決定であることを認識しています。最初の意図は、実際には「抽象化のレイヤーを追加する」ことでした。アプリがintどこでも使用される前に、科学的なソース コードを使用しており、オーバーフローの問題により、プログラムを機能させるためにソース コード全体ですべてをint置き換える必要がありました。long私たちが提示された問題で。そのためigraph_integer_t、単純なintorの代わりに、データ型が問題に対して小さすぎるlongことがわかった場合は、ソース コードの 1 か所だけを変更する必要があります。igraph_integer_t
振り返ってみると、上記のシナリオは非常にまれであるため、おそらくかなり弱い議論です。さらに複雑なことに、データ型がすべてのプラットフォームで十分でない場合を恐れて、igraph_integer_t型定義されています。(私が今考えることができる 1 つのシナリオは、大きなグラフでモチーフを数えることです。モチーフの数は整数ですが、古いプラットフォームではデータ型の制限を簡単に超える可能性があります)。決定が下された当時はプロジェクトの周りにいなかったので、正確な理由ではないかもしれません. igraph-help メーリング リストでお気軽に質問してくださいdoublelonglongigraph_integer_tあなたが血みどろの詳細に興味があるなら。とにかく、私は igraph の C コアを直接よく使用します (私は Python ラッパーを担当しているため)、次igraph_integer_tの 2 つの場合を除いて、他のデータ型との間でキャストする必要はないと安全に言えます。
igraph_integer_tで値を使用する場合printf。igraph_integer_taにキャストしてフォーマット文字列でlong使用するか、キャストを%ld行わずにフォーマット文字列で使用する必要があります (暗黙的に a に%g依存します)。igraph_integer_tdouble
を使用して配列にインデックスを付ける場合igraph_integer_t。明らかにそれをにキャストする必要がありlongます。
これは、多くのライブラリが正当な理由もなく行っているかなり厄介な方法です。の型を調べigraph_integer_tます。それがintであると私が期待している場合は、どこでも使用して、存在しないintふりをしてください。igraph_integer_tキャストは絶対に必要ありません。すべての整数 (および浮動小数点) 型は C で暗黙的に変換され、Ctypedef型は定義と区別されないと見なされます。
可能かどうかはわかりませんが (このパッケージはわかりません)、独自のアプリケーションで igraph_integer_t を使用するか、igraph の周りにフレームワークを構築して通信する必要があります。
問題は、間違ったサイズの整数 (short と long、signed と unsigned など) を使用すると、見つけにくい非常に風変わりなバグが発生する可能性があることです。使用しているライブラリとコンパイラに適切なサイズの int を選択する igraph と対話するフレームワークを構築します。安全であることがわかっているこのフレームワーク以外では、キャストは避けます。
一言で言えば、抽象化のレイヤーを追加します。