避免过多的铸造

Question

我目前正在开展一个涉及在图表中搜索和移动元素的项目。我认为 igraph 包非常适合我的简单需求，但是，因为我习惯使用java，所以有些事情并不清楚。

例如，为什么创建igraph包的人重新定义整数等基本元素为'igraph_integer_t'？ 有没有办法避免每次调用它们的库函数时都必须将所有内容都转换回整数，因为这会使代码变得非常混乱？

Answer 1

作为igraph的作者之一，我确实意识到这是一个可疑的设计决策，是在项目的最初阶段做出的。最初的意图是“添加一个抽象层”：我们在应用程序使用int到处之前使用了科学源代码，并且由于溢出问题，我们不得不用int替换每个long整个源代码中的igraph_integer_t使程序能够解决我们提出的问题。这就是为什么我们int而不是简单long或igraph_integer_t - 如果您发现igraph_integer_t数据类型对于您的问题来说太小，则必须只更改一个放在源代码中。

回想起来，上述情况非常罕见，所以它可能是一个非常弱的论点。为了进一步复杂化，double是long的类型定义，因为担心long数据类型在所有平台上都不够用的情况。 （我现在可以想到的一个场景是计算大图中的图案 - 图案的数量虽然是整数，但很容易超过旧版平台上igraph_integer_t数据类型的限制。由于当时关于igraph_integer_t的决定不在项目周围，这可能不是确切的原因，这正是我认为的可能。如果您对gory detals感兴趣，请随时询问igraph-help mailing list。无论如何，我直接使用igraph的C核心（因为我负责Python包装器），所以我可以肯定地说除了两种情况之外不需要在igraph_integer_t和其他数据类型之间进行转换：

1. 在printf中使用igraph_integer_t值时。您必须将long转换为%ld并在格式字符串中使用%g，或者不进行任何转换并在格式字符串中使用igraph_integer_t（隐式地依赖double为igraph_integer_t）。

2. 使用long索引数组时。您显然必须将其转换为{{1}}。

Answer 2

这是一个相当讨厌的做法，很多图书馆没有充分的理由。查找igraph_integer_t的类型。如果它是int，我期望它是，只需在任何地方使用int并假装igraph_integer_t不存在。绝对不需要演员阵容。所有整数（和浮点）类型都在C中隐式转换，并且C typedef类型无论如何都不被认为与它们的定义不同。

Answer 3

我不知道是否可能（我不知道这个包），但你应该在你自己的应用程序中使用igraph_integer_t，或者建立一个围绕igraph的框架供你沟通。

问题是，如果你使用错误的大小整数（短与长，签名与未签名等），那么你可能会得到一些很难找到的奇怪错误。我将构建一个与igraph交互的框架，为您正在使用的库和编译器选择适当大小的int。我会避免施放，除非在这个框架中你知道它应该是安全的。

简而言之：添加一层抽象。