On Mon, Oct 28, 2013 at 8:38 AM, Martin Dobias <wonder...@gmail.com> wrote: > On Thu, Oct 24, 2013 at 9:40 PM, Radim Blazek <radim.bla...@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 _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer