Proposal for 64-bit (row count) wxGridTableBase

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
lfishel
In need of some credit
In need of some credit
Posts: 3
Joined: Fri Dec 27, 2019 10:28 pm

Proposal for 64-bit (row count) wxGridTableBase

Post by lfishel »

I'm pretty new to wxWidgets... I could very much use a version of wxGridTableBase (and wxGrid and a couple of associated classes) that can handle more than 2 BILLION (2^31) rows. I probably need in the range of 2^50 or so to be safe (and future-proof), so all storage and parameters probably need to be upgraded from int to int64_t. I've done a lot of work, in the past upgradong our code to handle int64_ts, so I can probably build modified versions from existing code. I think they should probably use slighly different class names, say wxGridTableBase64 and such, because changing parameter types will probably be problematic for at least some existing users. I thought I should check here before I embark on this, in case someone has already started similar and I haven't found it yet... Is anyone aware of a project like this already in the works?
Thanks.
User avatar
doublemax
Moderator
Moderator
Posts: 19160
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Proposal for 64-bit (row count) wxGridTableBase

Post by doublemax »

Can't you just use a 64 bit build of your application?
Use the source, Luke!
lfishel
In need of some credit
In need of some credit
Posts: 3
Joined: Fri Dec 27, 2019 10:28 pm

Re: Proposal for 64-bit (row count) wxGridTableBase

Post by lfishel »

I *AM* using a 64 bit build. My problem is that the members and parameters that represent the number of rows in the grid object, and associated classes are defined as type int, which is rather loosely defined in the C/C++ standards, and in my version of gcc, it resolves it to a 32-bit integer. So, regardless of what architecture it's compiled for, the range is only 0-2^32... That's why I was so happy when stdtypes.h became so widely available... Now changing the types to int64_t will even behave correctly on 32-bit machines, ones advanced enough to emulate 64-bit types...
I first ran into this issue around 1990, when the Macintosh C compiler used 16-bit ints, so some code that we had been using on the DEC Alpha misbehaved on the mac.
User avatar
doublemax
Moderator
Moderator
Posts: 19160
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Proposal for 64-bit (row count) wxGridTableBase

Post by doublemax »

I see. And there is no switch for GCC that makes it create 64 bit integers by default?

To discuss changes in the wx code base, please post again on the wx-users mailing list, where you can reach the core wx developers. This here is a user forum.

https://groups.google.com/forum/#!forum/wx-users
Use the source, Luke!
lfishel
In need of some credit
In need of some credit
Posts: 3
Joined: Fri Dec 27, 2019 10:28 pm

Re: Proposal for 64-bit (row count) wxGridTableBase

Post by lfishel »

I'll move to the appropriate forum. Thanks.

Just after posting this, I thought thar gcc MIGHT have an option to to force int to 64-bit. My interpretation of the man page is that I can force 32-bit, but not 64-bit. If I COULD force 64-bit, I doubt that existing code would handle edge-case math correctly...
Nunki
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Fri Sep 14, 2012 8:26 am
Location: Kontich, Belgium
Contact:

Re: Proposal for 64-bit (row count) wxGridTableBase

Post by Nunki »

Hi,

First question that pops into mind is: will it be a workable situation ? I would guess that filling the grid with so many rows would take up a lot of time. Users may not like the long wait.

regards,
Nunki
User avatar
doublemax
Moderator
Moderator
Posts: 19160
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Proposal for 64-bit (row count) wxGridTableBase

Post by doublemax »

Nunki wrote: Wed Jan 08, 2020 10:18 am Hi,

First question that pops into mind is: will it be a workable situation ? I would guess that filling the grid with so many rows would take up a lot of time. Users may not like the long wait.

regards,
Nunki
In a "virtual" control that doesn't store any data, but only requests data when it's needed (e.g. to display on screen), that's not an issue.
Use the source, Luke!
Post Reply