paulo1205
(usa Ubuntu)
Enviado em 11/09/2013 - 00:56h
clodoaldoPeres escreveu:
Cara este teu código tah bem estranho. Quando se trabalha com arquivo deve se usar algumas funções importantes como fflush() - limpar o buffer pois a cada leitura stdin pode estar sujo comprometendo a veracidade da informação, ferror() - pois as operações com arquivo podem gerar erros a qualquer instante,etc. Sugiro que você abra teu arquivo em modo binário (para mim é muito melhor para trabalhar, se possivel) usando fopen com "rb" e use um ponteiro com o tamanho total do teu arquivo (você consegue ter o tamanho do arquivo com a função ftell(<ponteiro de arquivo>)) e use fread(void *buffer,size_t <qntd de bytes a serem lidos>,1,<ponteiro de arquivo>) passando o um ponteiro de char alocado com malloc ( p = (char*) malloc(<tamanho do arquivo> * char) ) e aí o teu ponteiro de char vai ter todo o teu arquivo então vc pode fechar o arquivo com fclose()/close() e o teu arquivo vai estar em buffer aí é soh navegar nele usando os indices como se fosse um vetor de char's
Meu caro,
Cuidado com as coisas que você diz. Observe que:
1) Oficialmente (i.e. de acordo com o padrão do C em suas três revisões: 1989/1990, 1999 e 2011),
fflush() nunca se destinou a limpar buffers de leitura, mas tão somente a forçar a gravação imediata (e não o descarte!) de informação em streams
de saída. É, portanto, JUSTAMENTE O OPOSTO do que você afirmou. (A invenção estúpida de usar
fflush() em buffers de entrada, particularmente
stdin, foi uma cretinice implementada
antes de existir um padrão para o C nos compiladores voltados para MS-DOS, cujo buffer de teclado se limitava a apenas quinze caracteres, e portanto tinha um funcionamento relativamente bem comportado e definido. Só que essa porcaria sobreviveu, por questões de compatibilidade com implementações passadas, mesmo após a padronização da linguagem C e sua biblioteca. Essa desgraça acabou incorporada nos compiladores para Windows e infelizmente foi importada recentemente também para o Linux, cujos buffers de teclado podem ser arbitrariamente longos e podem, portanto, nunca ser satisfatoriamente ou controladamente esvaziados.)
2) Ele está testando, sim, o sucesso da leitura, ao tomar o valor de retorno de
fgets() e verificar se ele é nulo. Se para ele não fizer diferença entre não conseguir ler por se ter chegado ao fim do arquivo ou em decorrência de algum erro (o que, aliás, é uma situação não muito comum em operações de leitura, especialmente num sistema monoprogramado), por que ele deveria testar o que não lhe interessa?
3) A julgar por outra postagem do mesmo autor, ele parece estar usando Windows. No Windows, se ele quiser trabalhar com arquivos de texto, é bom que ele NÃO USE "rb", mas sim somente "r", porque as funções de leitura e escrita de texto fazem conversões entre representações internas de fim de linha e a representação usada pelo sistema operacional. No mundo UNIX, "r" e "rb" são equivalentes, mas nos mundos Microsoft e MacOS, não.
4) É muito perigoso sugerir ler todo o arquivo para a memória. Você sabe o tamanho do arquivo? Sabe quanto de memória o programa tem disponível? Então é mais seguro trabalhar com arquivos, lendo linha a linha (e limitando mesmo o tamanho de cada linha, como ele fez).
5) O programa dele é mesmo voltado a trabalhar linha a linha. Assim sendo, ainda que ele estivesse trabalhando com tudo em memória, seria mais simples ter um array de linhas do que um megabuffer de caracteres individuais.