あまりにも多くの鋳造を避ける

Question

私は現在、&要素をグラフで検索するプロジェクトに取り組んでいます。私はigraphパッケージが私の単純なニーズにはかなり良いと思っていましたが、私はJavaを扱うのに慣れていたので、いくつかのことは明らかではありません。

なぜ、igraphパッケージを作成した人は、整数のような基本要素を 'igraph_integer_t'として再定義するのでしょうか？ ライブラリの関数を呼び出すたびに、すべてを整数にキャストしなくても済むようにする方法はありますか？

Answer 1

私はこのパッケージがわからないが、自分のアプリケーションでigraph_integer_tを使用するか、igraphの周りに通信するためのフレームワークを構築する必要があります。

間違ったサイズの整数（短いものと長いもの、署名されたものと署名されていないものなど）を使用すると、見つけにくい本当に風変わりなバグが発生することがあります。私は、使用しているライブラリとコンパイラに適切なサイズのintを選択するigraphとやりとりするためのフレームワークを構築します。私はあなたが安全でなければならないことを知っているこのフレームワーク以外のキャスティングを避けるでしょう。

一言で言えば、抽象レイヤーを追加します。

Answer 2

これは、正当な理由がないにもかかわらず、ライブラリの多くの嫌な習慣です。タイプは、igraph_integer_tです。私が期待しているのがintの場合は、どこでもintを使用し、igraph_integer_tのふりは存在しません。キャストは絶対に必要ありません。とにかくすべての整数型（および浮動小数点型）はCで暗黙的に変換され、C typedef型はその定義とは区別されません。

Answer 3

igraphの著者の一人として、私はこれがプロジェクトの最初の段階でなされた疑わしい設計上の決定であることを認識しています。初期の意図は、実際には「抽象レイヤーを追加する」ことでした。アプリケーションがintのどこにあってもオーバーフローの問題が発生する前に科学的ソースコードを使って作業しましたが、intをすべてソースコード全体に置き換えなければなりませんこのプログラムは私たちが提示した問題を扱っています。そのため、単純にintまたはlongの代わりにigraph_integer_tが表示されます。igraph_integer_tデータ型が問題に対して小さすぎる場合、ソースコード内の1つの場所のみを変更する必要があります。

上記のシナリオは非常にまれですので、おそらくかなり弱い議論です。すべてのプラットフォームでlongのデータ型では不十分な場合があるため、igraph_integer_tはdoubleにtypedefされます。 （私が考えることのできるシナリオの1つは、大きなグラフのモチーフを数えることです - モチーフの数は整数ですが、古いプラットフォームのデータ型の制限を簡単に超えることができます）。 igraph_integer_tについての決定がなされた当時のプロジェクトの周りではなかったので、それは正確な理由ではない可能性があります。もしあなたが落ち着きに興味があるなら、igraph-help mailing listでお気軽にお問い合わせください。とにかく、私はigraphのCコアを直接使用しています（私はPythonラッパーを担当しています）ので、igraph_integer_tと他のデータ型の間でキャストする必要はないと言うことができます。

1. printfにigraph_integer_tの値を使用する場合。igraph_integer_tをlongにキャストし、フォーマット文字列に%ldを使用するかキャストしないでフォーマット文字列に%gを使用する必要があります（暗黙のうちにigraph_integer_tがdoubleになっています）。

2. igraph_integer_tで配列にインデックスを付ける場合。あなたは明らかにそれをlongにキャストしなければなりません。