避免过多的铸造

发布于 10-04 11:09 字数 210 浏览 7 评论 0原文

我目前正在开展一个项目,其中涉及搜索和移动图表中的元素。我认为 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

如梦2024-10-11 11:09:58

作为 igraph 作者之一,我确实意识到这是在项目一开始就做出的一个有问题的设计决策。最初的意图实际上是“添加一个抽象层”:我们之前已经使用过科学源代码,应用程序在任何地方都使用 int ,并且由于溢出问题,我们不得不替换每个 intlong 贯穿源代码,使程序能够解决我们遇到的问题。这就是为什么我们有 igraph_integer_t 而不是简单的 intlong - 如果您发现 igraph_integer_t 数据类型是对于您的问题来说太小了,您只需更改源代码中的一处即可。

回想起来,上述情况相当罕见,因此这可能是一个相当薄弱的论点。让事情变得更复杂的是,由于担心 long 数据类型在所有平台上都不够用,因此将 igraph_integer_t 类型定义为 double 。 (我现在能想到的一个场景是在一个大图中计算主题 - 主题的数量虽然是整数,但很容易超出旧平台上long数据类型的限制)。由于当时做出关于 igraph_integer_t 的决定时并不参与该项目,因此这可能不是确切的原因,这只是我认为可能的原因。如果您对此感兴趣,请随时在 igraph-help 邮件列表上询问血淋淋的细节。不管怎样,我经常直接使用 igraph 的 C 核心(因为我负责 Python 包装器),所以我可以有把握地说,不需要在 igraph_integer_t 和其他数据类型之间进行转换,除了在两种情况下:

  1. printf 中使用 igraph_integer_t 值时。您要么必须将 igraph_integer_t 转换为 long 并在格式字符串中使用 %ld,要么不进行任何转换并使用 >%g 在格式字符串中(隐式依赖于 igraph_integer_tdouble)。

  2. 使用 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 every int with long all across the source code to make the program work with the problem we were presented with. So that's why we have igraph_integer_t instead of simply int or long - if you find that the igraph_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 a double for fear of cases when the long 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 the long data type on older platforms). Since wasn't around the project at that time when the decision about igraph_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 betweeen igraph_integer_t and other data types except in two cases:

  1. When using an igraph_integer_t value in printf. You either have to cast igraph_integer_t to a long and use %ld in the format string, or don't do any casting and use %g in the format string (which implicitly relies on igraph_integer_t being a double).

  2. When indexing an array with an igraph_integer_t. You obviously have to cast it to a long.

北渚2024-10-11 11:09:58

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

This is a rather nasty practice lots of libraries do for no good reason. Look up the type of igraph_integer_t. If it's int, which I expect it is, just use int everywhere and pretend igraph_integer_t does not exist. There's absolutely no need for casts. All integer (and floating point) types convert implicitly in C, and C typedef types are not considered distinct from their definitions anyway.

瑾夏年华2024-10-11 11:09:58

我不知道是否可能(我不知道这个包),但是您应该在自己的应用程序中使用 igraph_integer_t ,或者围绕 igraph 构建一个框架供您进行通信。

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

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

I don't know if it's possible (I don't know this package), but you should be using igraph_integer_t in your own application, or else building a framework around igraph for you to communicate with.

The thing is, if you use the wrong size integer (short vs. long, signed vs. unsigned, etc.) then you may get some really quirky bugs that are hard to find. I would build a framework to interact with igraph that picks the appropriately size int for the library and compiler you are using. I would avoid casting except in this framework where you know it should be safe.

In a nutshell: add a layer of abstraction.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文