避免过多的铸造
我目前正在开展一个项目,其中涉及搜索和移动图表中的元素。我认为 igraph 包非常适合我的简单需求,但是,由于我习惯于使用 java,所以有些事情并不清楚。
例如,为什么创建 igraph 包的人将整数等基本元素重新定义为“igraph_integer_t”? 有没有办法避免每次调用他们库的函数时都必须将所有内容转换回整数,因为这会使代码变得非常混乱?
I am currently working on a project which involves searching&moving elements in graphs. I thought the igraph package was pretty good for my simple needs, however, as I am a used to working with java, some things aren't clear.
Why, for instance, do the folks who created the igraph package redefine basic elements like integers as 'igraph_integer_t' ?
Is there a way to avoid having to cast everything back to integers every time I call a function of their library, as this makes the code pretty messy?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
发布评论
评论(3)
~没有更多了~
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
作为 igraph 作者之一,我确实意识到这是在项目一开始就做出的一个有问题的设计决策。最初的意图实际上是“添加一个抽象层”:我们之前已经使用过科学源代码,应用程序在任何地方都使用
int
,并且由于溢出问题,我们不得不替换每个int
和long
贯穿源代码,使程序能够解决我们遇到的问题。这就是为什么我们有igraph_integer_t
而不是简单的int
或long
- 如果您发现igraph_integer_t
数据类型是对于您的问题来说太小了,您只需更改源代码中的一处即可。回想起来,上述情况相当罕见,因此这可能是一个相当薄弱的论点。让事情变得更复杂的是,由于担心
long
数据类型在所有平台上都不够用,因此将igraph_integer_t
类型定义为double
。 (我现在能想到的一个场景是在一个大图中计算主题 - 主题的数量虽然是整数,但很容易超出旧平台上long
数据类型的限制)。由于当时做出关于 igraph_integer_t 的决定时并不参与该项目,因此这可能不是确切的原因,这只是我认为可能的原因。如果您对此感兴趣,请随时在 igraph-help 邮件列表上询问血淋淋的细节。不管怎样,我经常直接使用 igraph 的 C 核心(因为我负责 Python 包装器),所以我可以有把握地说,不需要在igraph_integer_t
和其他数据类型之间进行转换,除了在两种情况下:在
printf
中使用igraph_integer_t
值时。您要么必须将igraph_integer_t
转换为long
并在格式字符串中使用%ld
,要么不进行任何转换并使用>%g
在格式字符串中(隐式依赖于igraph_integer_t
为double
)。使用
igraph_integer_t
索引数组时。显然,您必须将其转换为long
。As one of the igraph authors, I do realise that this is/was a questionable design decision that was made in the very beginning of the project. The initial intention was really to "add a layer of abstraction": we've worked with scientific source code before where the app used
int
everywhere and due to overflow problems, we had to replace everyint
withlong
all across the source code to make the program work with the problem we were presented with. So that's why we haveigraph_integer_t
instead of simplyint
orlong
- if you find that theigraph_integer_t
data type is too small for your problems, you have to change only one place in the source code.In retrospect, the above scenario is pretty rare, so it's probably a pretty weak argument. To complicate things further,
igraph_integer_t
is typedef'd to adouble
for fear of cases when thelong
data type isn't enough on all platforms. (One scenario I can think of right now is counting motifs in a large graph - the number of motifs, although being integer, can easily exceed the limits of thelong
data type on older platforms). Since wasn't around the project at that time when the decision aboutigraph_integer_t
was made, it might not be the exact reason, this is just what I think might have been. Feel free to ask on the igraph-help mailing list if you are interested in the gory detals. Anyway, I use the C core of igraph directly a lot (since I'm responsible for the Python wrappers), so I can safely say that there is no need for casting betweeenigraph_integer_t
and other data types except in two cases:When using an
igraph_integer_t
value inprintf
. You either have to castigraph_integer_t
to along
and use%ld
in the format string, or don't do any casting and use%g
in the format string (which implicitly relies onigraph_integer_t
being adouble
).When indexing an array with an
igraph_integer_t
. You obviously have to cast it to along
.