How to handle mixing of different libraries (eg. stl and eigen3) that use different types for indices (size_t, int, ...)

Question

I have following problem. I have some code that uses Eigen3. Eigen3 uses int or long int for indices. At some points in the code I have to store values from the eigen-arrays in a std::vector.

Here is some example:

std::vector myStdVector;
Eigen::VectorXd myEigen;
....

for(size_t i=0; i<myStdVector.size(); i++)
{
    myStdVector[i] = myEigen(i);
}

Here I get the compiler warning:

warning: implicit conversion loses integer precision: 'const size_t' (aka 'const unsigned long') to 'int'

So of course I could add a static_cast<int>(i) to all the functions where such a scenario occurs, but I wonder if there is a better way to deal with such things. I guess this happens with many other "library-mixing" too.

Do you know what subset of each library's index type's range is actually used to store indices? Or, less generally, do you know whether Eigen3 allows negative index values to be stored in its indices? — Justin Time - Reinstate Monica, Sep 08 '19 at 18:57
I'm not sure if there is a case where the index could get negative in Eigen3, but I have not seen one so far. — goaran, Sep 08 '19 at 20:44
Okay, that's useful to know. Means both should at least be _viable_. — Justin Time - Reinstate Monica, Sep 08 '19 at 22:26

Justin Time - Reinstate Monica · Accepted Answer · 2019-09-08T23:05:55.183

In this specific case, I would suggest using the smaller container's index type; this would be Eigen's index type, as determined by your Eigen::VectorXd. Ideally, it would be used as Eigen::Index, for forwards-compatibility.

It might also be worth looking into how Eigen defines its index type. In particular, you are allowed to redefine it if necessary, by changing a preprocessor directive, by #defineing the symbol EIGEN_DEFAULT_DENSE_INDEX_TYPE; it defaults to std::ptrdiff_t.

^{[Note, however, that in my own code, I generally prefer to use the larger index (in this case, size_t), but do range checks as if using the smaller of the index types if applicable (in this case, Eigen::Index). This is just a personal preference, however, and not necessarily what I consider to be the best option.]}

Generally, when trying to choose the best index type, I would suggest that you look at their available ranges. First, if one or more of the potential types are signed, and if one or more signed potential type allows negative values^*, you'll want to eliminate any unsigned types, especially ones that are larger than the largest signed type. Then, you'd look at your use case, eliminate any types that aren't viable for your intended purpose, and choose the best fit out of the remaining potential types.

In your case specifically, you want to store values from an Eigen3 container in an STL container, where the Eigen3 container is indexed with ptrdiff_t and (as mentioned in your comment) to your knowledge only uses non-negative index values. In this case, either is a viable option; the range of non-negative index values provided by ptrdiff_t fits nicely inside size_t's range, and the loop condition will be determined by your VectorXd (and thus is also guaranteed to fit inside the Eigen3 container's index type). Thus, both potential types are viable choices. As the additional range provided by size_t is currently unnecessary, I would consider the index type provided by your Eigen setup to be slightly better suited to the task at hand.

^{*: While it's typically safe to assume that index values will always be positive due to how indexing works, I can see a few cases where allowing negatives would be beneficial. These are typically rare, though.}

^{Note that I assumed the loop condition i<myStdVector.size() in your example code was a typo, due to not lining up with the initial description or the operation performed inside the loop body. If I was incorrect, then this decision becomes more complex.}

How to handle mixing of different libraries (eg. stl and eigen3) that use different types for indices (size_t, int, ...)

1 Answers1