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

List:       koffice-devel
Subject:    Re: KSpread sheet size (was: Question to use of malloc in KSpread)
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-03-08 6:31:30
[Download RAW message or body]

Am Mittwoch, 6. März 2002 23:47 schrieb aleXXX:
> On Tuesday 05 March 2002 22:27, Philipp Müller wrote:
> > Am Montag, 4. März 2002 22:36 schrieb jodailey:
> > > What I would actually like to see is to use a small class or structure
> > > to refer to a cell.  This would simplify things greatly later if we
> > > want to change the storage of a row/column as an int, long, Q_UINT32,
> > > some dynamic and unlimited number, whatever.  At that point it would
> > > only mean changing the internals of the class instead of redoing nearly
> > > every function call in most all kspread files.
> >
> > John,
> >
> > how about in kspread_global.h
> >
> > #define KS_ROW Q_UINT32
> > #define KS_COL Q_UINT16
>
> Why not also Q_UINT32 ?
> It doesn't save memory or anything else.
It does save memory (you need always a map of pointers for all cells per 
table, at least with the current design) and it saves especially computation 
time (not much but it's for each cell).

If I we change it like above, then it's always easy to change and enhance, but 
currently even I don't see a reason for more than 65535 columns.
Just wait and see for a user demanding it and we can enhance easily.
The other way round is more complicated.

Philipp
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]