• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

Cypher

Algo estranho se passa aqui...

29 mensagens neste tópico

Tenho uma funçao que dentro dela invoca uma 2 funçao

void cod_bitwise (unsigned short index,unsigned short lenght,unsigned short ch){

     unsigned short bit_final=0;
     int i;
     
     index<<=11;
     lenght<<=7;
     
     bit_final=(index | lenght | ch);
     
     send_2_file (bit_final);
     
  //   printf("bitwaise =%u.",bit_final);
  //   printf("size of do int =%d",sizeof(short));
}

E o problema é no decorrer do programa a funçao cod_bitwise chama a funçao send_2_file, mas se eu meter outra instruçao a seguir desta  send_2_file (bit_final); faz, tudo bem

senao tiver nenhuma instruçao depois do send_2_file se meter logo o } nao faz nada...

ou seja  da maneira que esta aqui nao me faz nada  :(

ja esprimentei por com returns e nada...como é que resolvo isto... ?

cumps..

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

nessa função não vejo nenhum problema... se calhar o problema está na send_2_file.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

é melhor mostrares o código da função  send_2_file  também não vejo nenhum problema aí...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

é melhor mostrares o código da função  send_2_file  também não vejo nenhum problema aí...

nao da funçao send_2_file, nao é mesmo... isso tenho a certeza...

mas também já está o problema resolvido  :) afinal dá mesmo com um return....

problema resolvido...

int cod_bitwise (unsigned short index,unsigned short lenght,unsigned short ch){

     unsigned short bit_final=0;
     int i;
     
     index<<=11;
     lenght<<=7;
     
     bit_final=(index | lenght | ch);
     
     send_2_file (bit_final);
    return 0;
}

cumps...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Podes ter "resolvido" o problema, mas não ficaste a perceber porquê...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Pois isso é verdade...

void send_2_file(unsigned short bit){
     
     FILE *fp;
        
     if ( (fp = fopen(n_fich, "a+")) != NULL){

    fwrite(&bit, sizeof(unsigned short), 1, fp);

    fclose(fp);
}

    else
printf("Impossivel abrir o ficheiro\n\n");

     
}

o n_fich é uma string... não é dai o problema.

cumps...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Podes ter "resolvido" o problema, mas não ficaste a perceber porquê...

... porque estava a usar C ?  :hmm:
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Podes ter "resolvido" o problema, mas não ficaste a perceber porquê...

... porque estava a usar C ?  :hmm:

?? não percei essa...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

#include <stdio.h>

const char n_fich[] = "coiso.txt";

void send_2_file(unsigned short bit){     
FILE *fp;        
if ( (fp = fopen(n_fich, "a+")) != NULL){ 
	fwrite(&bit, sizeof(unsigned short), 1, fp); 
	fclose(fp);
}	
else
	printf("Impossivel abrir o ficheiro\n\n");	
fclose(fp);     
}
void cod_bitwise (unsigned short index,unsigned short lenght,unsigned short ch){

unsigned short bit_final=0;     
index<<=11;
lenght<<=7;     
bit_final=(index | lenght | ch);     
send_2_file (bit_final);
}

int main()
{
unsigned short a ,b,c;
a = 212;
b = 10;
c = 1;
cod_bitwise(a,b,c);
return 0;
}

:hmm:  este código compilado no gcc funciona, ao contrário do que te acontece...

o meu palpite é que está a haver algum problema do compilador no protótipo e/ou epílogo da função cod_bitwise , mas não sei explicar porquê  :bored:

já agora.. que compilador estás a usar ? Eu estou em windows com o djgpp

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

um debugger é capaz de ajudar a descobrir o problema...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Também concordo em como usar um debugger é o melhor para perceberes onde está o teu erro. Podias colocar aqui o source file completo e já agora que comando usas para compilar o teu código. Não me parece que mudares o tipo de retorno de uma função de

void

para

int

e colocando um

return 0

que isso vá alterar o que quer que seja em termos de execução...  :dontgetit: mas só mesmo vendo o código todo e fazendo debug  :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não me parece que mudares o tipo de retorno de uma função de para e colocando um que isso vá alterar o que quer que seja em termos de execução...  :dontgetit:

[ infelizmente? ] poder, pode. Aqueles que tiveram assembly sabem o que é o protótipo e o epílogo duma função. Neste caso o problema parece ser o epílogo (quando a função retorna), o facto de ser void ou retornar um inteiro é diferente.

Se calhar o que acontece é k o compilador não está a fazer o epílogo correctamente no caso de uma função void, porque qualquer função tem de retornar ao ponto em que foi chamada. Mas também não me parece que um compilador possa ter este problema  :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Podes ter "resolvido" o problema, mas não ficaste a perceber porquê...

... porque estava a usar C ?  :hmm:

?? não percei essa...

O C às vezes parece que fica possesso...

Já aconteceu a um colega meu, que após a optimização do código de uma função ficou com algumas variáveis que estava a usar antes e que já não usava mais. Ao tirar a declaração da variável (era um int) o programa craxava, com a declaração da variável funcionava às mil maravilhas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não me parece que mudares o tipo de retorno de uma função de para e colocando um que isso vá alterar o que quer que seja em termos de execução...  :dontgetit:

[ infelizmente? ] poder, pode. Aqueles que tiveram assembly sabem o que é o protótipo e o epílogo duma função. Neste caso o problema parece ser o epílogo (quando a função retorna), o facto de ser void ou retornar um inteiro é diferente.

Se calhar o que acontece é k o compilador não está a fazer o epílogo correctamente no caso de uma função void, porque qualquer função tem de retornar ao ponto em que foi chamada. Mas também não me parece que um compilador possa ter este problema  :)

O que eu queria dizer era que mal o fluxo de execução passe por essa função (que foi alterada para retornar um int ), não é por colocar um return 0 que vai fazer com que a execução subitamente consiga sair dessa função quando isso não acontecia anteriormente (quando não retornava nenhum tipo de dado)!! Logicamente que uma função que retorna seja que tipo de dados for, tem que retornar e o fluxo de execução tem que continuar obviamente como disseste, se não ocorrerem erros entretanto. Se o código for correctamente programado e compilado, essa função cod_bitwise funciona perfeitamente bem mesmo não retornando nenhum tipo de dados, como te mostra o exemplo do mogers. Não me parece que seja qualquer problema com o prólogo ou o epílogo, muitas das vezes o problema em questão é bem mais simples do que o que pensamos.  :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Só naquela... já que não parece existir problema em lado nenhum.

Retira o fclose(fp) que está a mais.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Bem ate posso disponibilizar o programa ... mas ja leva mais de 500 linhas de codigo, pessoalmente nao acho muito, acho muito sim tar a analizar um programa de inicio assim...

já agora estou a utilizar o Dev C++...  mas acontece me uma cena engraçada ja esprimentei compilar no c++ 3.0 e com o gcc nu Ubunto e dá bem enquanto no dev nao faz nada... agora se meter o return funciona em todos...

cumps...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O C às vezes parece que fica possesso...

Já aconteceu a um colega meu, que após a optimização do código de uma função ficou com algumas variáveis que estava a usar antes e que já não usava mais. Ao tirar a declaração da variável (era um int) o programa craxava, com a declaração da variável funcionava às mil maravilhas.

Quando o programador faz erros, o C queixa-se.

Até te digo o que aconteceu aí: estavas a aceder a uma posição de memória ilegal num vector, por exemplo v[5] num "int v[5];". Como tinhas declarado o outro inteiro logo de seguida, ficaram contíguos na memória e ele retornava esse inteiro no v[5], logo não dava erro. Ao retirar a sua declaração, passa a dar.

O C não fica possesso. É uma linguagem demasiado aperfeiçoada para ter problemas desses. O programador é que por vezes faz asneiras e não sabe porquê.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O C não fica possesso. É uma linguagem demasiado aperfeiçoada para ter problemas desses. O programador é que por vezes faz asneiras e não sabe porquê.

apesar de tudo, não é impossível que os processadores tenham bugs... mesmo o gcc (que deve ser o melhor que aí anda) deve ter alguns, mas isto acontece com todas as linguagens.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Claro que é possível os compiladores terem bugs, mas não me parece que seja quem está a aprender, no dia-a-dia, que os encontre. São as excepções, e a termos de bugs dos compiladores, devido ao uso intensivo, diria que C ainda está mais protegido do que qualquer outra linguagem..

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O C às vezes parece que fica possesso...

Já aconteceu a um colega meu, que após a optimização do código de uma função ficou com algumas variáveis que estava a usar antes e que já não usava mais. Ao tirar a declaração da variável (era um int) o programa craxava, com a declaração da variável funcionava às mil maravilhas.

Quando o programador faz erros, o C queixa-se.

Até te digo o que aconteceu aí: estavas a aceder a uma posição de memória ilegal num vector, por exemplo v[5] num "int v[5];". Como tinhas declarado o outro inteiro logo de seguida, ficaram contíguos na memória e ele retornava esse inteiro no v[5], logo não dava erro. Ao retirar a sua declaração, passa a dar.

O C não fica possesso. É uma linguagem demasiado aperfeiçoada para ter problemas desses. O programador é que por vezes faz asneiras e não sabe porquê.

Obvio, daí dizer parece.. porque segundo o compilador estava tudo bem.

E mais, a função em questão não trabalhava com apontadores (arrays incluídos), simplesmente algures noutra parte do programa o meu colega devia estar a fazer algo errado. Mas deu para dar umas boas gargalhadas visto que o trabalho em questão tinha-se a liberdade de fazer em qualquer linguagem e ele foi dos poucos que optou por C e um simples int x; dava erro :)

É claro que ele ficou a olhar para o código durante 2 dias e depois lá resolveu fazer um rm -f e perder mais um par de dias a reescrever tudo o que já tinha feito e ficou tudo a funcionar às mil maravilhas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Claro que é possível os compiladores terem bugs, mas não me parece que seja quem está a aprender, no dia-a-dia, que os encontre. São as excepções, e a termos de bugs dos compiladores, devido ao uso intensivo, diria que C ainda está mais protegido do que qualquer outra linguagem..

Isso é verdade de todas as linguagens que conheço o C parece ser o mais perfeito de todas... Pascal, um simples utilizador, encontra logo um pouco de erros, nem é necessário usar muito para aparecer logo os primeiros erros, o delphi será uma boa escolha para substituir o pascal ... VB nem devia comentar  :P gosto da linguagem... fazem-se programas  :) em pouco tempo, e com bom interface ... agora erros também é ele o Rei  :biggrin: , e assim os outros compiladores igual, menos ou mais lá tem os seus erros...

Agora não sei se é pela linguagem C ter a dimensao, quantidade de programadores de C, que chega a ser a mais perfeita ( em termos de erros ) que todas as outras...mas lá ha-de de ter os seus erros, concordo com o Warrior não os deve encontrar quem está a aprender, no dia-a-dia.

Para mim não ha nenhum programa perfeito  :P ( um bocado do meu lado perfeccionista )

cumps...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

por exemplo v[5] num "int v[5];".

Onde? Não encontro declarações de vectores no código.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

por exemplo v[5] num "int v[5];".

Onde? Não encontro declarações de vectores no código.

não estao a falar do meu codigo... foi um exemplo que o Warrior deu...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

o Warrior tava a falar do problema referido pelo Betovki  :)

O C não fica possesso. É uma linguagem demasiado aperfeiçoada para ter problemas desses. O programador é que por vezes faz asneiras e não sabe porquê.

Não podia estar mais de acordo  :biggrin:  Realmente, muita gente culpa sempre o C quando tem problemas "inexplicáveis" , quando o erro está do nosso lado.

No ultimo semestre tive uma cadeira que misturava C com funções assembly, e nas funções assembly assediamos a variáveis e funções definidas no código em C ( código principal) , aí sim era uma mina de erros desse género. Nestas alturas com um debugger podemos gastar 1 horita (nem sei se tanto), "à mão" como o amigo do Betovski gastou 2 dias  :hmm:

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Claro que é possível os compiladores terem bugs, mas não me parece que seja quem está a aprender, no dia-a-dia, que os encontre. São as excepções, e a termos de bugs dos compiladores, devido ao uso intensivo, diria que C ainda está mais protegido do que qualquer outra linguagem..

já fiz com que o gcc abortasse na compilação, por estar a aceder (propositadamente) a posições fora do vector. na melhor das hipóteses, o gcc devia avisar que tinha um erro no código ou algo assim, mas não, abortou!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora