ex:

typedef struct {
	char name[128];
	int id;  		  	
	char rg[128];
} tpessoafisica;

A concepcao de que existe uma compatibilidade binaria entre duas estruturas eh algo incrivel que abre a possibilidade de considerarmos o polymorphismo, mas ao mesmo tempo exige que os programadores saibam com que tipo de coisa estao lidando.

Obviamente a aritmetica de ponteiros e a correcao dos index de acesso aos elementos (de um array ou de uma estrutura) estao diretamente ligadas a plataforma onde a coisa estah sendo executada e ao se desenvolver com este tipo de estrategia em mente eh importante ter BEM claro quais os limites a serem considerados.

Outro dia ouvi desenvolvedor que C nao era portavel por exemplo, pq voce poderia criar programas que andem por regioes especificas de memoria e isso nao vai funcionar atraves de plataformas/SOs… Clara ma interpretacao tanto do conceito de portabilidade quanto do uso dos mecanismos de acesso a memoria que o C tao elegantemente nos oferece.

Essa compatibilidade binaria que tu alega tem seus reveses aos quais eh preciso estar atento ao trabalhar… Imagine por exemplo que tu pretenda alocar espaco para trabalhar com estas estruturas… apesar da compatibilidade binaria e do cast te permitir o polymorphismo, ao alocar espaco, tu precisas ter ciencia do tamanho da MAIOR estrutura… Isso em linguagens de nivel superior eh burlado de forma que um array de um determinado objeto nao contem o objeto em si, mas sim uma referencia para ele, o que pode obviamente ser obtido em C com uma array de ponteiros para as structs (o que ao contrario do que muita gente pensa NAO VAI ADICONAR NENHUM IMPACTO DEVIDO A DERREFERENCIA, pois a quantidade de passos para interepretacao eh a mesma que se a struct estivesse de fato na array).

O ponto eh que, embora esse poder seja amplo e interessante, possibiltando os pontos que tu apontou e muitos outros, o programador ao utilziar este tipo de beneficio, precisa estar ciente de suas implicacoes, e muitos nao estao!

A origem disso eh a falta de conhecimento da linguagem e o preconceito que alguns programadores tem sobre certos aspectos… seguindo o exemplo do desenvolvedor que questionou sobre a portabilidade de codigo, no meio da conversa ele falou, que um char ocupa 2 Bytes na memoria, o que eh um pressuposto equivocado baseado no estudo de C especifico das plataformas (antigas) da Intel… Para o C, um char e um int ocupam o mesmissimo espaco na memoria, ateh pq nao existe como se enderecar somente parte de uma palavra e portanto seu espaco eh igual a no minimo o tamanho da palavra… obviamente que para quem programa dentro do padrao, isto nao tem nenhum impacto significativo e passa despercebido, mas certamente quem carrega preconceitos como esse vai ter problemas ao tentar alocar espaco para Strings por exemplo, ou vai sofrer com ponteiros selvagens em algum momento, simplesmente pq pressupos alguma coisa que de fato nao condiz com a realidade da plataforma… O triste eh que essas pessoas se acham, baseado nisso, no direito de sair soltando maximas como: “C nao eh portavel!”… Faltou fazer a licao de casa… #fail

Valeu pelo post Pac, eh muito bom ver alguem resgatando os conceitos que deveriam ser basicos a maioria dos desenvolvedores mas que sao sumariamente ignorados e geram tanta confusao por aih!

> v.10

perl -E ‘for(1000..9999){say$_,if((int($_/100)+$_%100)==sqrt($_))}’

seq 10 99 | gawk ‘(int($1*$1/100) + $1*$1%100 == $1) {print $1*$1}’

Não é recomendável começar o ensino por C ou Java ou, muito menos, Ruby. Elas não são didáticas, apesar de serem simples. Uma coisa não é sinônimo da outra.

Mas em uma segunda instância, é essencial adotar logo um C.
Uma evolução meio que Pascal – C – Depois um C++ ou Java mesmo…

Infelizmente, eu comecei a aprender por VB :s.. Tosco neh? Depois veio Java, C, Ruby, C++…. Caminho bem controverso, eu acho…

Aí cara, vi teu link no blogroll do evento MSX no sábado agora. Vai lá?