[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Kspread row limit
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2009-12-30 11:32:34
Message-ID: 200912301232.34713.boud () valdyas ! org
[Download RAW message or body]

On Tuesday 29 December 2009, Tomas Mecir wrote:
> 2009/12/29 Tomas Mecir <mecirt@gmail.com>:
> > The PointStorage class already operates on "int"s, so no change is needed
> > there.
> 
> A quick follow-up, as this is not entirely correct after all:
> PointStorage is addressing cells using one number, so the number needs
> to be able to hold any number up to max-rows * max-cols. It uses the
> "int" datatype to do this, so if you raise the limits such that their
> product no longer fits into a 32-bit number, you will need to use
> something like qint64 there to prevent problems on 32-bit platforms.

I wonder whether it  would be possible to use a trick similar to utf8 or utf16 
to have the best of both worlds, where you'd use more bytes to store the 
location for the higher row/col numbers, and less bytes for the lower numbers. 
I guess Microsoft must be using a trick like this in the latest version of 
Excel.

Maybe it's possible to deduce something about this from the actual Excel row 
limits (1,048,576 rows, 16,384 columns, maxr * maxc = 1,717,9869,184, 
according to Hendrik).

-- 
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]