避免过多铸造

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。