EOF dúvida relacionada ao Post respondido pelo Paulo [RESOLVIDO]

paulo1205
(usa Ubuntu)

Enviado em 30/06/2020 - 04:31h

Não é apenas melhor. É necessário.



EOF não é perigoso, e é, sim, confiável. Perigoso e não-confiável é comparar um valor do tipo int, como EOF, com um valor do tipo char. Também é perigoso converter para char um valor do tipo int que pode estar fora da faixa representável por um char ou que possa ser representado de modo ambíguo ou dependente da implementação.



Você quer dizer uma variável do tipo int para guardar o caráter lido? Se sim, isso é perfeitamente seguro e sempre foi o jeito certo de trabalhar com funções de leitura caráter-a-caráter, desde os primórdios do C.



Você pode confiar em EOF, até porque seu valor é constante.

Existem outras formas saber se você atingiu o fim de arquivo, sim. Mas se você vai ler todo o arquivo, até o fim, a indicação de EOF retornado por uma função de leitura é a primeira coisa a ser testada.

Só que você tem de ter em mente que o valor EOF é devolvido também em casos de erro. Tais erros são raros, mas se você quiser ter certeza absoluta que a leitura foi interrompida por fim de arquivo, e não por erro, convém testar o arquivo para saber a causa. Para isso, existem em C as funções feof() e ferror(), e eventualmente clearerr(), especialmente em caso de erros transitórios, ou de chegar ao fim de um arquivo que pode crescer logo em seguida. Em C++, os equivalentes são std::ios::eof(), std::ios::fail() (para erros potencialmente recuperáveis) e std::ios::bad() (para erros não-recuperáveis), além de std::ios::clear() para reajustar as sinalizações de erro.



A menos que você tenha uma boa razão para ler um caráter de cada vez, se o arquivo for de texto, geralmente é mais fácil ler linha a linha.

Se o arquivo for binário, pode ser interessante ler em blocos de bytes (std::istream::read()).



Não sei do que você está falando. Pode mostrar o trecho de código que exemplifica o problema?

Pelo que vi em outra mensagem sua, eu receio que você possa confundir, em algumas situações, char (tipo usado para guardar apenas um caráter) com char * ou const char *, que são tipos de ponteiros usados para indicar em que posição de memória começa uma string. Cuidado, portanto, para não misturar alhos com bugalhos.



Não conheço “assigned”, mas, pelo contexto, acho que você quis dizer simplesmente signed.

Nada disso é invenção do C++. Se você acaha burocrático, é justamente para manter compatibilidade com C.



Não é proibido converter const char em char.

Você está se referindo a ponteiros? Esses, sim, não são permitidos diretamente, porque isso pode produzir uma violação de proteção de acesso do objeto apontado. O ponteiro foi declarado como constante por um motivo; se você quer violar essa restrição, é bom saber muito bem o que está fazendo, e tem de indicar isso claramente no código através da palavra-chave const_cast.

E note que isso não se aplica apenas a ponteiros para caracteres constantes, mas a ponteiros para qualquer tipo de objeto constante (const int *, const double *const (ponteiro constante para valor double constante), char *const * (ponteiro (não-constante) para ponteiro constante para caráter (não-constante)) etc.).



Não é tudo letra. Muito pelo contrário: tudo é número.

Lembre-se do sentido original de “computador”. É mero acidente histórico nos referirmos a máquinas que fazem uma quantidade relativamente grande de contas com pouca interação humana como “computadores” e a máquinas que fazem uma conta de cada vez, sob estrito controle humano, como “calculadoras” — até porque existem híbridos como calculadoras programáveis e computadores mecânicos.

Acho um tanto engraçadas suas reclamações porque, além dos exageros (“300 mensagens de erro”, “1 milhão de objetos”), elas acabam revelando um tanto de desconhecimento a respeito da máquina que você está usando, da ferramenta que está empregando e da história de ambas.

O tipo char, apesar do nome que tem, não se destina a guardar caracteres. Ele é um tipo numérico: o menor tipo numérico inteiro que a máquina for capaz de endereçar (desde que esse tipo numérico tenha pelo menos oito bits). O nome “char” foi aplicado a esse tipo de dados porque, na época em que a linguagem foi criada (na verdade, adaptada a partir da linguagem B), esse tipo “inteiro de oito bits de largura” era suficiente para representar qualquer um dos 128 caracteres do ASCII (7 bits), que a máquina que o hospedava usava, e ainda podia guardar também os códigos numéricos usados nos cartões perfurados de mainframes da IBM (EBCDIC, cujos caracteres são distribuídos de um jeito tal em o 8º bit tem de ser usado).

Aliás, você sabia que não existe, em C, um jeito direto (i.e. que não envolva conversão explícita de tipo) de produzir uma constante literal cujo tipo seja char? Quando você escreve algo como 'a' ou '\n' (usando apóstrofos), os valores correspondentes são do tipo int, não do tipo char.

Historicamente falando, quando o C foi criado, no UNIX do PDP-11, char era com sinal (ou seja: seus valores iam de -128 até 127), porque essa era a forma mais natural de trabalhar nesse equipamento, especialmente por causa de um tipo de operação, que é a operação de converter de byte (ou do menor inteiro representável) para o tipo inteiro natural da máquina (com 16 bits ou mais). No caso do PDP-11, essa conversão se dava pela extensão do bit mais significativo (que é o bit de sinal) do byte original para todos os outros bits do valor inteiro. Isso fazia pleno sentido no PDP-11 por dois motivos: porque era a forma mais eficiente de fazer naquela arquitetura (o processador fazia isso naturalmente), e porque isso é consistente com a representação de números negativos usando notação de complemento a dois (por exemplo: o valor -15 pode ser representado em um byte binário como 11110001; ao ser convertido para inteiros de 16 bits, o mesmo valor -15 é representado como 11111111 11110001; ou seja, o bit mais à esquerda na representação como char era 1, e foi copiado todos os bits a mais que um inteiro de 16 bits possui).

Quando o UNIX e o C foram portados para outras máquinas, os implementadores notaram que algumas delas tinham instruções de conversão de byte para tipos inteiros maiores (de 16 ou 32 bits) que preenchiam os bytes mais significativos com zeros, em vez de estender o bit mais significativo do byte para a esquerda. Em máquinas assim, se o byte fosse com sinal, você tinha duas opções: usar uma operação custosa a cada conversão de byte para inteiro nativo (e vice-versa), ou usar uma conversão mais rápida, mas que sempre produziria inteiros positivos, mesmo que o byte original fosse negativo. O que o pessoal do C decidiu foi que, em máquinas assim, o melhor seria usar a operação mais eficiente, e considerar todos os bytes como sempre positivos.

Obviamente, esse tipo de coisa acabou produzindo alguma confusão, com programas que de comportavam de modos diferentes quando compilados em máquinas diferentes. Para acabar com a confusão o padrão da linguagem decidiu criar três tipos de dados distintos: signed char, unsigned char e char. Os dois primeiros têm comportamentos muito bem definidos em qualquer máquina, a despeito do custo computacional que possam causar. O terceiro tem normalmente o comportamento que for mais eficiente para cada implementação.

Veja o seguinte trecho de programa.

// Arquivo “x.c“.



char fc(char c){ return ~c; }

unsigned char fuc(unsigned char c){ return ~c; }

signed char fsc(signed char c){ return ~c; }



int g(int i){

	char c=i;

	unsigned char uc=i;

	signed char sc=i;

	return fc(c)+fuc(uc)+fsc(sc)+fuc(c)+fsc(c);

}



int h(void){ return g('\300'); }  // -64 ou 192.  Note que isso é um int!



// As funções abaixo são declaradas mas não definidas, porque estou mais

// interessado no que acontece dentro de j().

// A função fr() é só para impedir o compilador de otimizar demais o código

// envolvendo a variável r, dentro de j().

char fpc(const char *pc);

void fr(const int *);



int j(void){

	char c='c';

	unsigned char uc='u';

	signed char sc='s';

	int r=0;

	fr(&r);

	r+=c;

	fr(&r);

	r+=uc;

	fr(&r);

	r+=sc;

	r+=fpc(&c);           // OK: tipo do ponteiro perfeitamente compatível.

	r+=fpc((char *)&uc);  // Se tirar os casts dos ponteiros, dá erro, mesmo que uma

	r+=fpc((char *)&sc);  // das variáveis tenha a mesma representação interna que c.

	return r;

} 

Se você o compilar de uma forma a gerar o código em Assembly correspondente (por exemplo, usando o comando “gcc -Wall -Werror -pedantic-errors -S -fverbose-asm -O1 -fno-inline x.c”, que vai produzir o arquivo de saída x.s) e examinar tal código, vai ver algumas coisas interessantes:

  • Em todas as operações aritméticas, que misturam signed char com unsigned char, todos os operandos são convertidos para int, mesmo que o destino do resultado só tenha um byte de comprimento (isso é uma regra do C, e é um bom motivo para preferir tipos de dados que produzam conversões eficientes, sempre que isso for possível).

  • Ao converter de byte para int, nossos PCs com Intel ou AMD empregam a instrução do Assembly movsbl (na notação da AT&T, que normalmente o Linux utiliza; se for com a notação da Intel, o nome da instrução é MOVSX), que significa “movimentar (copiar) o valor de um byte (“b”), estendendo para 32 bits (“l” ou “X”) por meio da cópia para a esquerda do bit de sinal (“s”). Tal instrução é usada tanto com char não qualificado quanto com signed char, o que significa que eles têm a mesma representação interna e, portanto, produzem resultados semelhantes, mas não os torna equivalentes, pois esse comportamento pode mudar se o programa for levado para outra máquina, ou mesmo se, na mesma máquina, o compilador for invocado com uma configuração diferente.

  • Ao converter de unsigned char para int, a instrução do Assembly empregada é movzbl (ou MOVZX), que indica que os bits à esquerda devem ser preenchidos com zeros. Até algumas gerações de processadores atrás, essa instrução era ligeiramente mais lenta do que a outra (fonte: https://gmplib.org/~tege/x86-timing.pdf).

  • Converter de inteiro para qualquer tipo de byte, nos nossos PCs, é feito simplesmente através do truncamento dos bits à esquerda. Contudo existem máquinas em que isso pode não ser verdade (por exemplo, máquinas que usem representações inteiras do tipo sinal+magnitude ou deslocamento binário)


Você se queixou do C++, mas na verdade o C++ não é responsável por nenhuma das esquisitices acima. Elas são parte da linguagem C, e o C++ herdou algumas delas tão-somente para manter compatibilidade com C.

Por outro lado, o C++ quebrou algumas das esquisitices do C. Por exemplo, em C++, uma constante literal de caráter, tal como 'P', '\n' ou '\123' tem tipo char, em vez de int. Isso é necessário para que funções sobrecarregadas com argumentos de tipos diferentes possam funcionar adequadamente.

Outra melhoria do C++ foi implementar a classe std::string, que ajuda a diminuir as dificuldades de manipular strings que o C tem.



Ué, e não é assim no C? Se ele errar na sintaxe, o programa nem compila. Se ele errar na semântica, o programa faz o melhor que pode, seguindo literalmente o que tiver sido dito.



... Então Jesus afirmou de novo: “(...) eu vim para que tenham vida, e a tenham plenamente.” (João 10:7-10)