You want to build a text editor. Maybe it’s a modern replacement for Vi or a fresh take on Notepad. It doesn’t matter. The goal is simple: let users edit standard ASCII files.
Think about how often programmers actually use these tools. It’s their primary interface with the machine. It’s where thoughts become code. Naturally, you want it to feel right. You want it to be fast. You want it to handle your specific workflow. So, you decide to build your own.
The first hurdle is data structure. How do you store the text in memory? You need a way to manipulate the characters quickly. Your initial instinct? Lines of text.
You grab an array. Simple enough. A typical line is 80 characters. A typical file has maybe 1,000 lines. You declare a two-dimensional array:
That’s 80,000 characters. Manageable. Clean.
But then reality hits. You think about edge cases.
Some files are massive log lists. Thousands of lines, each barely 10 characters long.
Other files are special-purpose data dumps. One line might contain 542 characters representing amino acid pairs in a DNA sequence.
And modern editors let you open multiple files simultaneously. Let’s say you cap it at 10 open files. You set a hard limit of 1,000 characters per line and 50,000 lines per file.
Now your declaration looks like this:
You crunch the numbers. 50,000 times 1,000 times 10. That’s 500 million characters.
Most computers can’t handle that. Even with virtual memory, it’s a strain. Run three instances of your editor on a multi-user system, and you’re choking the RAM. It’s an extravagant waste. You’re allocating space for the absolute worst-case scenario, when most users are just editing 100-line files that take up 4,000 bytes.
The problem with arrays is rigid. You must declare the maximum size in every dimension upfront. Those dimensions multiply. And if someone tries to open a file with a 2,000-character line? You’re out of luck. Line length is technically infinite. You can’t predict it.
This is why pointers exist.
How Pointers Solve Memory Waste
Pointers allow you to build dynamic data structures. Instead of reserving static space in advance, you allocate memory from the heap while the program runs.
You use the exact amount of memory the document needs. No waste. When you close a file, you return that memory to the heap. Other parts of the program can use it. Memory gets recycled.
It’s not just about saving space. It’s about flexibility. You don’t need to guess the maximum line length. You allocate what you need, when you need it.
If you’re still wondering what a byte actually is, or how “mega” and “giga” translate to real-world constraints, go read up on bits and bytes. Then come back. You’ll need to understand the hardware limits to appreciate why static arrays fail here.
