Как один из авторов igraph, я понимаю, что это сомнительное дизайнерское решение, которое было принято в самом начале проекта. Первоначально предполагалось «добавить слой абстракции»: раньше мы работали с научным исходным кодом, где приложение везде использовало int, и из-за проблем переполнения пришлось заменить все int на long все через исходный код, чтобы заставить программу работать с проблемой, с которой мы были представлены. Вот почему у нас есть igraph_integer_t вместо простого int или long - если вы обнаружите, что тип данных igraph_integer_t слишком мал для ваших проблем, вам придется изменить только одно место в исходном коде.
В ретроспективе приведенный выше сценарий довольно редок, поэтому, вероятно, это довольно слабый аргумент. Чтобы усложнить ситуацию, igraph_integer_t является typedef'd к double из-за боязни случаев, когда тип данных long недостаточно на всех платформах. (Один из сценариев, о котором я могу подумать сейчас, - это подсчет мотивов на большом графике - число мотивов, хотя и является целочисленным, может легко превысить пределы типа данных long на старых платформах). Поскольку в то время, когда было принято решение о igraph_integer_t, его не было вокруг проекта, возможно, это не является точной причиной, я думаю, это было именно так. Не стесняйтесь спрашивать в списке рассылки igraph-help , если вы заинтересованы в кровавых деталях. В любом случае, я часто использую ядро C в igraph (так как я отвечаю за оболочки Python), поэтому я могу с уверенностью сказать, что нет необходимости в приведении между igraph_integer_t и другими типами данных, кроме двух случаев:
При использовании значения igraph_integer_t в printf. Вы должны либо привести igraph_integer_t к long и использовать %ld в строке формата, либо не выполнять преобразование и использовать %g в строке формата (что неявно полагается на igraph_integer_t, являющуюся double).
При индексировании массива с igraph_integer_t. Вы, очевидно, должны привести его к long.