Question

Why are programs like Microsoft Excel, Gnumeric and OpenOffice.org Calc designed with hard-coded limits on the number of rows and columns? This seems like an archaic programming technique from when spreadsheets were considered a demanding application and dynamic memory allocation was considered "high-end". I would guess that it indicates that some resource is being statically allocated, with the assumption that "noone will ever need more than that", thus introducing a very arbitrary limitation into the application. What is the logic behind it?

Note: I know some people are going to argue that this question isn t programming related. Here s a preemptive rebuttal: This question is programming-related because it s asking why a pervasive and seemingly obsolete programming methodology is used.

Answer 1

The original reason was for performance and space, because (for instance) handling 65536 rows only requires two bytes. These historic reasons have gone with Office 2007 (if not the others as well), so your question is also obsolete.

Answer 2

Because it s way easier to handle cell references as a pair of indexes and they end up having a limit?

In short, there will be a limit no matter what you do, the question is just what will it be, what will it cost to make it that and how many people will run into it?

Answer 3

Next Gnumeric version will allow much larger sheets, up to 8M rows and 8k columns. Just if you really need such large sheets, buy some TBytes of RAM.

Answer 4

In Excel97 biff record,column is stored as 0xff number,row is stored as 0xFFFF numner. So it limite the col to 255 and the row to 65535,if you want to save more rows/cols in Excel2003(if it is support in IDE),it will not be saved.

友情链接