Você deseja construir um editor de texto. Talvez seja um substituto moderno para o Vi ou uma nova versão do Bloco de Notas. Não importa. O objetivo é simples: permitir que os usuários editem arquivos ASCII padrão.
Pense na frequência com que os programadores realmente usam essas ferramentas. É a interface principal com a máquina. É onde os pensamentos se tornam código. Naturalmente, você quer que pareça certo. Você quer que seja rápido. Você deseja que ele lide com seu fluxo de trabalho específico. Então, você decide construir o seu próprio.
O primeiro obstáculo é a estrutura de dados. Como você armazena o texto na memória? Você precisa de uma maneira de manipular os personagens rapidamente. Seu instinto inicial? Linhas de texto.
Você pega uma matriz. Bastante simples. Uma linha típica tem 80 caracteres. Um arquivo típico tem talvez 1.000 linhas. Você declara um array bidimensional:
São 80.000 caracteres. Gerenciável. Limpar.
Mas então a realidade bate. Você pensa em casos extremos.
Alguns arquivos são listas de log enormes. Milhares de linhas, cada uma com apenas 10 caracteres.
Outros arquivos são despejos de dados para fins especiais. Uma linha pode conter 542 caracteres representando pares de aminoácidos em uma sequência de DNA.
E os editores modernos permitem abrir vários arquivos simultaneamente. Digamos que você limite 10 arquivos abertos. Você define um limite rígido de 1.000 caracteres por linha e 50.000 linhas por arquivo.
Agora sua declaração fica assim:
Você analisa os números. 50.000 vezes 1.000 vezes 10. São 500 milhões de caracteres.
A maioria dos computadores não consegue lidar com isso. Mesmo com memória virtual, é um esforço. Execute três instâncias do seu editor em um sistema multiusuário e você estará sobrecarregando a RAM. É um desperdício extravagante. Você está alocando espaço para o pior cenário possível, quando a maioria dos usuários está apenas editando arquivos de 100 linhas que ocupam 4.000 bytes.
O problema com matrizes é rígido. Você deve declarar antecipadamente o tamanho máximo em cada dimensão. Essas dimensões se multiplicam. E se alguém tentar abrir um arquivo com uma linha de 2.000 caracteres? Você está sem sorte. O comprimento da linha é tecnicamente infinito. Você não pode prever isso.
É por isso que existem ponteiros.
Como os ponteiros resolvem o desperdício de memória
Os ponteiros permitem construir estruturas de dados dinâmicas. Em vez de reservar espaço estático antecipadamente, você aloca memória do heap enquanto o programa é executado.
Você usa a quantidade exata de memória que o documento precisa. Sem desperdício. Ao fechar um arquivo, você retorna essa memória para o heap. Outras partes do programa podem usá-lo. A memória é reciclada.
Não se trata apenas de economizar espaço. É uma questão de flexibilidade. Você não precisa adivinhar o comprimento máximo da linha. Você aloca o que precisa, quando precisa.
Se você ainda está se perguntando o que realmente é um byte ou como “mega” e “giga” se traduzem em restrições do mundo real, leia sobre bits e bytes. Então volte. Você precisará entender os limites de hardware para entender por que os arrays estáticos falham aqui.
