c - 避免过多的铸造

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数据类型在所有平台上都不够用，因此将其定义为 a。（我现在能想到的一种情况是在一个大图中计算图案 - 图案的数量虽然是整数，但很容易超过long旧平台上数据类型的限制）。由于做出决定时当时不在项目周围igraph_integer_t，因此可能不是确切的原因，这正是我认为可能的原因。随时在igraph-help 邮件列表上提问如果你对血腥的细节感兴趣。igraph_integer_t无论如何，我经常直接使用 igraph 的 C 核心（因为我负责 Python 包装器），所以我可以肯定地说，除了两种情况外，不需要在和其他数据类型之间进行强制转换：

1. 使用 中的igraph_integer_t值时printf。您要么必须转换igraph_integer_t为 along并%ld在格式字符串中使用，要么不要在格式字符串中进行任何转换和使用%g（这隐含地依赖于igraph_integer_ta double）。

2. 使用igraph_integer_t. 您显然必须将其转换为long.

Answer 2

这是许多图书馆无缘无故地做的一种相当讨厌的做法。查找类型igraph_integer_t。如果它是int，我期望它是，只需int在任何地方使用并假装igraph_integer_t不存在。完全不需要演员表。所有整数（和浮点）类型都在 C 中隐式转换，并且 Ctypedef类型无论如何都不会被认为与它们的定义不同。

Answer 3

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

问题是，如果您使用了错误大小的整数（短与长、有符号与无符号等），那么您可能会遇到一些很难找到的非常古怪的错误。我将构建一个框架来与 igraph 交互，该框架为您正在使用的库和编译器选择适当大小的 int。我会避免强制转换，除非在这个框架中你知道它应该是安全的。

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