Re: [eigen] Signed or unsigned indexing

[ Thread Index | Date Index | More Archives ]

> actually, std random access iterators do accept signed indices as well. size_t indices are used at the container level only.
> This actually makes sense to me, considering that interfaces should be minimal and that unsigneds has a simpler
> set of invalid values when representing non negative quantities ( signeds need to specify the behaviour of
> passing two bounds instead of one,  this increases the complexity of documentation, pre/postcondition checks and tests ).

For pre/postcondition check, this is not really an issue as

T& operator[](std::ptrdiff_t i) {
  assert(static_cast<std::size_t>(i) < static_cast<std::size_t>(size()));

  return data_[i];

does not do more work than the unsigned version. I agree that it looks strange, but as it is inside a library, I am not worried.

> premising that I’m definitely in the signed party,  I think most signed/size_t interoperability problems come from using
> containers when iterators/ranges/views should be used; in my experience ( for what it’s worth :) ) if containers decays to views. ASAP most unsigned to signed indices conversions disappear, leaving just few controlled casts/checks where appropriate.

Many people still need to work with indices. If you work with an array of structure

struct Point {
  double x;
  double y;
  double z;

you can work with iterators. But if you work with a structure of array

struct ArrayPoint {
  std::vector<double> x;
  std::vector<double> y;
  std::vector<double> z;

it is much more easier to work with indices. Also, there are structure for which it is impossible to get efficient iterators, for instance a matrix where there is padding at the end of the matrix. Such structures can’t be traversed with iterators as efficiently as indices. So indices are still needed today.

Mail converted by MHonArc 2.6.19+