Hi, 2009/9/13 Markus Metz <[email protected]>: > AFAIKT, r38992 Vect_get_num return long has no effect because the number of > features (for each type) is stored as plus_t which is int. If you want to
Right, I postponed this problem, thanks for raising it up. > prepare the vector libs to support more than INT_MAX objects, I would > suggest to use > > plus_t Vect_get_num_primitives(const struct Map_info *, int); > > etc and then think about what type is appropriate for plus_t. Seems to be a good idea. > I would suggest *not* to use long because long is the same like int on 32 > bit (4 bytes) and the same like long long int on 64 bit (8 bytes), i.e. a > vector written with 64 bit may not be readable with 32 bit which is against > all the efforts to keep the vector format independent of > platform/architecture/compiler. Some unsigned integer type should work, else > some checks would be needed similar to what Glynn recently implemented to > get an integer type of size 8 in port_init.c. E.g. use long if possible else > use long long if possible else fatal error, no integer of size 8 available > (or is there something else that could have a size of 8 ?). Right, I will change long to plus_t for now. Martin -- Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
