Build fails on 32-bit architectures (size_t vs int)

[danfe]

I've tried versions 1.9.6 and 1.9.8, and they both fail to build on 32-bit architectures, e.g. i386 and ARM, apparently for the same reason: use of overloaded operator [] is ambiguous (with operand types INDI::PropertyNumber and int) because candidate function WidgetView<T> &operator[](size_t index) const; from indipropertybasic.h conflicts with built-in candidate operators (see the build logs linked above for the full error message). On 64-bit machines size_t is 64-bit (but int is still 32-bit) so there's no clash, and the code builds fine.

[pawel-soja]

I confirm.

For those interested, I wrote an example showing the problem:

#include <cstddef>

struct Foo
{

    void operator[](size_t)
    {
        /* ... */
    }

    operator Foo*()
    {
        return this;
    }
};

int main(int argc, char *[])
{
    Foo foo;
    foo[0];
    return 0;
}

/**
  * $ g++ -m32  main.cpp
  * main.cpp: In function ‘int main(int, char**)’:
  * main.cpp:22:10: warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
  *    22 |     foo[0];
  *       |          ^
  * main.cpp:8:10: note: candidate 1: ‘void Foo::operator[](size_t)’
  *     8 |     void operator[](size_t)
  *       |          ^~~~~~~~
  * main.cpp:22:10: note: candidate 2: ‘operator[](Foo*, int)’ (built-in)
  *    22 |     foo[0];
  *       |          ^
  */

As long as there are operators that ensure backward compatibility, problems may arise in determining the method of reference. https://github.com/indilib/indi/blob/22718d728fa1e24f8b3198e1ca08be33ecae9ae3/libs/indibase/property/indiproperty.h#L130-L131 Operators are needed to make this code work: https://github.com/indilib/indi/blob/22718d728fa1e24f8b3198e1ca08be33ecae9ae3/libs/indibase/defaultdevice.cpp#L994 where should it be:

 INDI::Property prop = getProperty(propertyName); 

The code is being refactored so that you can get rid of unnecessary operators in the future.

Currently, the solution I see is an application of the int type.

@knro what do you think? Prepare a patch (PR) changing size_t to int?