避免過多鑄造

Question

我目前正在研究一個涉及在圖中搜索&移動元素的項目。我認爲這個軟件包對我的簡單需求非常有用，但是，因爲我習慣於使用java，所以有些事情並不清楚。

例如，爲什麼創建igraph包的人重新定義了像整數這樣的基本元素爲'igraph_integer_t'？ 有沒有一種方法可以避免每次調用庫函數時將所有內容都轉換爲整數，因爲這會使代碼變得非常混亂？

Answer 1

我不知道是否有可能（我不知道這個包），但是你應該在你自己的應用程序中使用igraph_integer_t，或者在igraph周圍建立一個框架以供你進行通信。

問題是，如果你使用了錯誤的大小整數（短與長，簽名與未簽名等），那麼你可能會得到一些很難找到的真正古怪的錯誤。我會構建一個與igraph進行交互的框架，爲您正在使用的庫和編譯器選擇合適的int大小。除非在這個框架中，我知道它應該是安全的，否則我會避免投射。

簡而言之：添加一層抽象。

Answer 2

這是一個相當討厭的做法，很多圖書館沒有很好的理由。查找igraph_integer_t的類型。如果是int，我期望它是，只要使用int無處不在，假裝igraph_integer_t不存在。絕對不需要演員。所有的整數（和浮點數）類型都隱式轉換爲C，並且類型不會被視爲與它們的定義有所不同。

Answer 3

作爲igraph作者之一，我確實意識到這是/是項目開始時做出的可疑設計決策。最初的意圖實際上是「添加抽象層」：我們已經使用了科學源代碼，在應用程序在各處使用int之前以及由於溢出問題，我們必須在源代碼中全部替換每個int和long以使該計劃與我們提出的問題一起工作。所以這就是爲什麼我們有igraph_integer_t而不是簡單的int或long - 如果您發現igraph_integer_t數據類型對於您的問題來說太小，您只能更改源代碼中的一個位置。

回想起來，上述情況非常罕見，所以它可能是一個很弱的參數。更復雜的是，igraph_integer_t被鍵入double，因爲擔心所有平臺上的數據類型不足long。 （我現在可以想到的一種情況是在大圖中計算圖案 - 雖然是整數，但圖案的數量可以很容易地超過舊版平臺上long數據類型的限制）。由於當時並沒有圍繞這個項目做出關於igraph_integer_t的決定，所以這可能不是確切的原因，這只是我認爲的可能。隨意問igraph-help mailing list，如果你有興趣在血統detals。無論如何，我直接使用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。