Tristeza com Ponteiros em C++ [RESOLVIDO]

paulo1205
(usa Ubuntu)

Enviado em 11/05/2020 - 03:41h

Começando pelo fim.



Hehehe... A linguagem é o que é. Quem desrespeitou as regras delas foi você. Ela só está reclamando do mal que você fez a ela. ;)



Se é um compilador C++, não adianta fingir que é outra coisa. C++ parece muito com C em muitos pontos, mas é outra linguagem, com várias regras diferentes, mesmo em coisas básicas, tais como tipos de dados.

Se você quer que um bloco de código se comporte totalmente como C, compile-o com um compilador C, e junte com o código C++ apenas na hora de invocar o linker.

Contudo, eu sou uma daquelas pessoas que consideram o C++ melhor que o C, pelo motivo de que ele ajuda mais você a não fazer algumas bobagens óbvias do ponto de vista semântico, mas que não refletem essa questão semântica sintaticamente em C. Por exemplo: usar um ponteiro para dados não constantes para apontar para dados que são constantes é um erro semântico em qualquer linguagem que possua tipos de dados distintos, o que inclui o C e o C++. Nesse caso, essas características semânticas podem ser expressas sintaticamente e, em o sendo, o compilador pode forçar você a não misturar essas coisas distintas. E o compilador C++ faz isso de modo mais enérgico que o C. (O C também poderia ser enérgico, se quisesse, mas, por vários fatores — e suspeito que o principal fator entre eles sejam manter compatibilidade com código antigo — deliberadamente escolheu não ser.)



Esse é um exemplo de erro semântico com desdobramentos sintáticos a que eu me referi acima.

Tanto em C quanto em C++, o elemento sintático “"Nick"” é uma constante literal de string. Sendo uma constante, e tipo de "Nick" é “array com 5 elementos do tipo const char”. Como todo array, ele decai para um tipo ponteiro para o primeiro elemento quando utilizado em qualquer expressão que não seja sua declaração ou como operando de sizeof ou do operador unário & (ou ainda, no caso do C++, na hora de resolver argumentos de templates).

E qual o tipo do primeiro elemento? Não é const char? Então por que tentar atribuí-lo a um ponteiro para char não-constante? Isso é um erro semântico — seja em C++, seja em C!

O problema é que o C propositalmente — e, na minha opinião, bisonhamente — cria uma exceção para constantes literais de strings, dizendo que elas podem ser atribuídas diretamente a ponteiros para caracteres não-constantes, ainda que o compilador tenha meios de fazer com que a constante literal de string seja disposta em memória com proteção de ser somente para leitura (como, por sinal, têm e efetivamente fazem os compiladores modernos para nossos sistemas em arquitetura amd64/x86-64).

------ Contextualização histórica ------
Essa exceção do C é uma herança de tempos antigos em que, primeiramente, não existia a palavra-chave const na linguagem (antes do primeiro padrão da linguagem, que foi publicado em 1989; e, por sinal, const foi implementado primeiro em C++, e trazido para o C quando se viu que ela ajudava a tornar a programação mais segura), e, em segundo lugar, nem sempre se podia proteger a memória que guardava as constantes do programa (sobretudo em microcomputadores, mas mesmo em algumas máquinas de maior porte da época, não existiam tantos mecanismos de proteção de acessos a memória como existem hoje).

Quando veio o padrão de 1989 do C, achou-se por bem não criar um problema de compatibilidade para todos os programas que já usavam algo como “char *pA="Nick";”, dizendo-se que o decaimento de constantes literais de strings seria para ponteiros para caracteres, em vez de ponteiros para caracteres constantes.

(Às vezes eu fico cá pensando com meus botões se não foi um mero esquecimento: uma vez que a incorporação de const foi uma ação tardia do comitê de padronização, talvez tenham esquecido de rever o impacto dessa adoção em algumas partes do padrão que talvez já tivessem sido escritas, e talvez uma dessas partes fosse justamente a que descrevia o comportamento de constantes literais de strings. Acho também que foi uma escolha com resultado contraproducente: poder usar ponteiro para dados comuns só fez com que quase ninguém se esforçasse para usar ponteiros para dados constantes, mesmo que os dados sejam efetivamente constantes. Quanto mais tempo passou e continua passando, maior se vem tornando a quantidade de código sintaticamente válido mas semanticamente errado que terá ser corrigido para que o C possa requerer o uso de uma sintaxe que reflete o que já é semanticamente feito pelos compiladores.)
------ Fim da contextualização histórica ------

De todo modo, o fato é que o C tem essa infeliz característica de poder ter dados efetivamente constantes referenciados por ponteiros para dados não-constantes, e o C++ muito apropriadamente não copiou essa característica bisonha. Em C++, se o dado é constante, o ponteiro para ele também o é, e qualquer variável que receba tal ponteiro terá ter um tipo que explicite que o dado é constante.

Em C++, portanto, você tem de fazer do seguinte modo.

const char *pA="Nick";  // OK: array com 5 elementos do tipo const char decai para ponteiro para const char, e é atribuído a variável do mesmo tipo. 

Note que o código acima também é perfeitamente válido em C. Então eu sugiro que você passe a deixar explícito no seu código quando você que apontar para dados constantes, de modo a nunca incorrer em erro semântico, mesmo que o erro semântico não produza também um erro sintático.



No seu programa não vai fazer muita diferença mas, num caso geral, eu sugiro que você não mexa na variável que indica o tamanho alocado para linha lida.

Como o tamanho alocado e o comprimento efetivo são semanticamente diferentes e também geralmente são diferentes na prática (e o código acima indica que você sabe dessa diferença prática), utilize, sim, uma segunda variável para representar o comprimento da linha lida.



Sim, use rewind(). É melhor.



O mais provável é que o 22º caráter seja o indicador de fim de linha, que não é descartado pela função getline(). Se você não quiser mantê-lo, deve descartá-lo explicitamente após a leitura.



O valor muda porque você passa novamente ‘&Line_Size’ como argumento para getline() mais abaixo. Por isso mesmo, eu insisto: se você quer representar semanticamente uma outra coisa, use outra variável.



A linha que esta comentada acima declararia um array com 101 elementos do tipo ponteiros para caracteres. Não creio que você quisesse isso.



Parece-me que você não deveria incrementar Line_Content aqui dentro, já que ela já está sendo incrementada pela terceira expressão do for.

Mas isso, embora provavelmente errado, acaba sendo um problema menor. Note que ao alterar os valores dos ponteiros, você não vai mais apontar para os primeiros caracteres de cada um, mas sim para o que tiver acabado de ser copiado na iteração corrente do laço de repetição. Assim sendo, o mais provável é que, no final da cópia, os dois ponteiros fiquem apontando para uma posição (ou duas, dado que há incrementos em dois locais diferentes ao mesmo tempo) após o terminador da string, o que significa que você vai apontar para dados que nem mesmo conhece e que nem ao menos pertencem aos arrays.

Como ambos os ponteiros foram dinamicamente alocados (um através de getline() e o outro com new []), isso é particularmente mais grave, porque você não vai conseguir desalocá-los e, se tentar fazê-lo, os resultado são imprevisíveis.

Uma forma de corrigir isso (além da que eu apresento mais abaixo para substituir esse bloco inteiro) é você ter ponteiro adicionais para percorrer os espaços que foram alocados para LineContent e Add_Groups, mantendo elas próprias inalteradas, para que você possa tanto lembrar de onde as string começam quanto para poder desalocá-las quando for a hora de fazê-lo. Uma forma seria trocar a linha contendo o for acima para algo como

for(char *pCont=Line_Content, *pGroups=Add_Groups; *pCont; ++pCont++, ++pGroups) 

e depois trocar todas as ocorrências de Line_Content e Add_Groups dentro do laço de repetição por pCont e pGroups, respectivamente, e tirar alguns dos incrementos desses ponteiros dentro do laço de repetição, já que eles já estão sendo incrementados pela terceira expressão na linha de controle.



Essa desalocação será inválida porque você mudou o valor do ponteiro, a não ser que implemente a correção que eu indiquei acima.



Essa desalocação será inválida porque você mudou o valor do ponteiro, a não ser que implemente a correção que eu indiquei acima.

Mas mesmo que estivesse certo anteriormente (ou que você implemente a correção indicada), se você alocou com new[], desaloque com delete[]. Caso contrário, o resultado é imprevisível, com chances de fazer o programa capotar.

Mas melhor ainda, já que você está usando C++, é substituir todos esses ponteiros e operações de alocação e liberação implícitas ou explícitas por variáveis do tipo std::string, e também o trabalho com arquivos ao estilo do C por acesso a arquivo no modo padronizado pelo C++, com std::ifstream. Seu código ficaria muito mais limpo e menos propenso a erros. (Note que eu suprimi a primeira leitura do arquivo, porque ele é desnecessária não apenas nesta versão, mas o teria sido também na sua, se você não tentasse alocar espaço para o objeto antecipadamente.)

// No ínicio do arquivo
#include <fstream>
#include <string>

// Na sua função.
	std::ifstream MyFile(Path);
	std::string LineContent, AddGroups;
	unsigned lineNumber=0u;
	while(getline(MyFile, LineContent)){
		if(++lineNumber==3){
			for(char c: LineContent)
				switch(c){	// Uso switch em vez da tripa de ifs porque tende a gerar código mais eficiente, especialmente para um conjunto pequeno de valores possíveis.
					default:
						AddGroup+=c;
						break;	// Esse break é do switch, não do for; para sair de loops dentro de um switch tem-se de usar goto.
					case '\3':	// ETX
						AddGroups+=c;
						AddGroups+='\n';
						// Note o fall-through: aproveita o goto que está abaixo.
					case '\0':	// Supõe que o terminador de strings do C termina a string no arquivo.  Isso não necessariamente é verdade para strings do C++, que podem conter nulos sem problemas (desde que não sejam convertidas de/para strings do C).
						goto end_copy;
					case '\37':	// US (037 é a expressão em base octal do valor 31 em base decimal).
						AddGroups+='\n';
						// Fall-through: aproveita o break que está abaixo.
					case '\2':	// STX: não faz nada (no seu programa também não fazia).
						break;
				}
		end_copy:
			break;	// Sai do while.
		}
	}
	EdGroups->SetValue(AddGroups); 

Note como não precisa fechar o arquivo nem desalocar nada: os destrutores dos objetos fazem isso por você quando eles saírem de escopo.



Nada disso. Os erros que você cometeu, sobretudo quanto a mudar valores que deveriam permanecer constantes, não têm nada a ver com o C++ ou com o compilador. Continuariam erros se você usasse um compilador C.

E, por sinal, de novo erros semânticos, que, não tendo reflexo na sintaxe (mesmo em C++) não podem ser identificados pelo compilador.



Já mostrei uma alternativa, que é usar objetos do C++, em vez de se sacrificar com os recursos mais primitivos do C.

Mas se quiser de todo jeito fazer em C ou num estilo C-like, você ainda pode ler o arquivo numa única passada, e alocar a variável quando chegar até a terceira linha (até porque você só fez isso na primeira vez em que fez a leitura no código acima). O problema com isso é que existem caracteres no arquivo de entrada que se tornam dois caracteres na hora de converter, e a forma atual que você usa para alocar a string de destino não leva isso em consideração, mas deveria.

Uma correção é migrar logo para C++, deixando de ser C-masoquista. :)

Outra possibilidade é, ao alocar a string de destino, supor o pior caso e multiplicar por dois o tamanho da linha lida.

E existe ainda a possibilidade — que eu definitivamente não recomendo — de ir realocando a string de destino a cada caráter lido. Nesse caso você não poderá usar new []/delete[], mas sim malloc()/realloc()/free(),. Não poderá também usar um ponteiro como para fazer a cópia de caracteres com algo como “*pGroups++=*pCont++;” (ou “*pGroups=*pCont;”, já que a linha de controle do for já faz o incremento dos ponteiros), pois realloc() pode resolver mover os dados Add_groups para outra região de memória, invalidando o valor de pGroups; em lugar disso, você terá de trabalhar com um índice que indica o deslocamento em relação ao primeiro elemento (por exemplo: “Add_Groups[indice]=*pCont”



O C++ não tem culpa de nada aqui. As confusões são fruto de entendimento inadequado, e dariam problema também em C, Pascal, Assembly ou qualquer outra linguagens em que existam ponteiros.

Aliás, se ponteiros o deixam confuso, eis mais uma boa razão para preferir C++ a C. Ainda existem ponteiros em C++ mas, como ilustrou o programa que eu propus acima, seu uso direto para tarefas simples tende a ser menos necessário e mais controlado.


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