I think I may have brought this up some years ago, but I do not remember the discussion.
Why is igraph_bool_t defined as an int and not as a (space efficient) char?
I believe this was because R uses ints for Booleans. Probably @Gabor can tell more about this.
Yes, that’s correct.
We already have igraph_vector_char_t and similar.
Then I can use igraph_vector_bool_t for public APIs but use igraph_vector_char_t for purely internal boolean vectors, to save storage.
Sounds reasonable?
I guess I could also use a raw char * but that’s a pain to deal with.
1 Like
I think that is a reasonable approach. Semantically it might be more appropriate to have something like igraph_i_boolean_t, but that is not necessary.
We could even consider a igraph_bit_vector_t type which uses individual bits (and of course uses the most appropriate underlying int type), instead of entire chars, but that might involve more work to do properly, especially for vector operations.
@Gabor What about igraph_integer_t being int? Is that also restricted by the R interface, or is it feasible to change it?
It would be convenient to make it 32-bit on 32-bit platforms and 64-bit on 64-bit platforms.
It is not feasible to change it, I think, without a lot of work, and basically no gain? At least I don’t see the immediate gain.
@Gabor I wrote up some of the reasons here: https://github.com/igraph/igraph/issues/1450
@Gabor Could you please comment here? https://github.com/igraph/igraph/issues/1450 See my last message.