[Qgis-developer] QgsRasterBlock.setColor(size_t, QRgb) in SIP

[Radim Blazek]

On Mon, Oct 28, 2013 at 8:38 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
> On Thu, Oct 24, 2013 at 9:40 PM, Radim Blazek <radim.blazek at gmail.com> wrote:
>>
>> Then I get
>>
>>>>> block.setColor( 0, QColor ().rgb() )
>> Traceback (most recent call last):
>>   File "<input>", line 1, in <module>
>> TypeError: arguments did not match any overloaded call:
>>   QgsRasterBlock.setColor(int, int, int): not enough arguments
>>   QgsRasterBlock.setColor(int, int): argument 1 has unexpected type 'int'
>>
>> works with "unsigned long". In C++ I have size_t defined as "long
>> unsigned int" (gives compilation error if used in sip file) which
>> should be the same as "unsigned long" I believe.
>>
>> The problem is wrong definition of size_t in sip file. It should not
>> work for you as well, right? If you are on Linux you get "typedef
>> unsigned int size_t" in sip which is not the same as size_t in C++. I
>> guess that it accidentally works because by chance the memory used by
>> wider type is zeroed.
>
> Yes I also think it works just accidentally.
>
>>
>>> There was a thread on size_t in PyQt some time ago:
>>> http://www.riverbankcomputing.com/pipermail/pyqt/2006-March/012753.html
>>
>> Yes, I saw, quite old and no solution. If I look into stddef.h
>> (/usr/lib/gcc/x86_64-linux-gnu/4.6/include/stddef.h) the typedef of
>> size_t is quite complex.
>>
>> So how can we reliably define size_t in sip file?
>
> We should probably try to compile and run a tiny program (during CMake
> configure phase) that will return the value of sizeof(size_t) and from
> that generate a helper .sip file with correct definition for size_t.

Is it enough to check only size? I think that unsigned and signed have
also be distinguished.

> Not extremely elegant, but should work. The problem will be again with
> cross-compilation (e.g. Android) as we cannot run such utility program
> on target CPU, but we can hardcode the definition for such platforms.

This is used in GRASS to identify data types and byte order and I
would prefer to avoid it because of the problems with cross
compilation you mentioned.

> But maybe there's a better way I am not aware of...

Maybe the easiest would be to define our own

   typedef unsigned long qgs_size_t;


Radim

>> I mean what is the best practice to do that in QGIS. Would not it be
>> better to have shared definitions separated into some common.sip?
>
> Yes, that would be better.
>
>
> Martin