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 prepare the vector libs to support more than INT_MAX objects, I would suggest to use
etc and then think about what type is appropriate for plus_t.
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 ?).
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 ?).
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 prepare the vector libs to support more than INT_MAX objects, I
would suggest to use
etc and then think about what type is appropriate for plus_t.
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 ?).
#ifdef HAVE_LONG_LONG_INT
typedef long long longest; #else
typedef long longest; #endif
?
If you're desperate for more than 32 bits, an IEEE "double" can
represent integers between -2^53 and 2^53 exactly, but this is likely
to be more trouble than it's worth (you have to be careful with
division, you can't use a double as an array index, you can't use
shifts or bitwise operators, ...).
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 prepare the vector libs to support more than INT_MAX objects, I would suggest to use
etc and then think about what type is appropriate for plus_t.
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 ?).
#ifdef HAVE_LONG_LONG_INT
typedef long long longest; #else
typedef long longest; #endif
?
If you're desperate for more than 32 bits, an IEEE "double" can
represent integers between -2^53 and 2^53 exactly, but this is likely
to be more trouble than it's worth (you have to be careful with
division, you can't use a double as an array index, you can't use
shifts or bitwise operators, ...).
IMHO, we should first make sure that the vector libs support up to INT_MAX (2^31 - 1) features. Vector libs LFS was a first step, and unless there is a revolutionary new hardware concept in the near future with huge amounts of RAM and much higher processing speed, building topology for so many features will take a long long time, particularly in case of areas. One solution would be to increase the speed and decrease the memory requirements of topology building, and I think more brains should be put to that task before increasing the number of supported features, i.e. changing plus_t from a 32-bit integer type to a 64-bit integer type.
> #ifdef HAVE_LONG_LONG_INT
> typedef long long longest;
> #else
> typedef long longest;
> #endif
>
> ?
>
> If you're desperate for more than 32 bits, an IEEE "double" can
> represent integers between -2^53 and 2^53 exactly, but this is likely
> to be more trouble than it's worth (you have to be careful with
> division, you can't use a double as an array index, you can't use
> shifts or bitwise operators, ...).
>
IMHO, we should first make sure that the vector libs support up to
INT_MAX (2^31 - 1) features. Vector libs LFS was a first step, and
unless there is a revolutionary new hardware concept in the near future
with huge amounts of RAM and much higher processing speed, building
topology for so many features will take a long long time, particularly
in case of areas. One solution would be to increase the speed and
decrease the memory requirements of topology building, and I think more
brains should be put to that task before increasing the number of
supported features, i.e. changing plus_t from a 32-bit integer type to a
64-bit integer type.
It isn't just vector code which would benefit from a wide integer
type. Some raster code has problems with maps with more than 2^31
cells.