Guys,
Just fyi, a long on my machine (Linux 2.6.35.6-48.fc14.x86_64) is 8
bytes. It's the same as long long.
Dave
On 11/28/2010 02:39 PM, Even Rouault wrote:
Frank,
If I agree we can upgrade the C++ API of OGRLayer::GetFeature() and
DeleteFeature() to use GIntBig instead of long, I'm
David,
yes, on most 64bit platforms, sizeof(long long)=sizeof(long)=8. Except on Win64,
where sizeof(long) still = 4 ( see
http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models ). And of
course on 32bit platforms, sizeof(long)=4. So the need for an explicit 64bit API
is needed.
On 29/11/10 14:57, Even Rouault wrote:
David,
yes, on most 64bit platforms, sizeof(long long)=sizeof(long)=8. Except on Win64,
where sizeof(long) still = 4 ( see
http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models ). And of
course on 32bit platforms, sizeof(long)=4. So the need
On 11/29/2010 10:09 AM, Mateusz Loskot wrote:
On 29/11/10 14:57, Even Rouault wrote:
David,
yes, on most 64bit platforms, sizeof(long long)=sizeof(long)=8.
Except on Win64,
where sizeof(long) still = 4 ( see
http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models
). And of
Frank,
If I agree we can upgrade the C++ API of OGRLayer::GetFeature() and
DeleteFeature() to use GIntBig instead of long, I'm wondering whether the ABI
backward incompatible change of OGR_L_GetFeature() and OGR_L_DeleteFeature()
is something acceptable with respect to our (implicit) policy
Hi,
As I understand it the only reason to use 64bit integers for IDs would
be for tables with more than 2 billion records (in the positive range).
There is a related question on StackOverflow about this
http://stackoverflow.com/questions/2124631/sql-server-int-or-bigint-database-table-ids
Are
geographika wrote:
Hi,
As I understand it the only reason to use 64bit integers for IDs would
be for tables with more than 2 billion records (in the positive range).
There is a related question on StackOverflow about this
---Original Message---
From: geographika geograph...@gmail.com
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] RFC 31 - OGR 64bit Support
Sent: Nov 27 '10 06:17
Hi,
As I understand it the only reason to use 64bit integers for IDs would
be for tables with more
Folks,
In the interest of moving towards a GDAL/OGR 1.8 release I have done some
work on RFC 31 - 64bit integers for OGR fields and FIDs. I've updated the
RFC itself somewhat, and done a preliminary implementation of the RFC on
my own system with a reasonable level of success.
I'm asking for