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

bertolo

Zona de inicialização: é onde afinal?

14 mensagens neste tópico

#include <stdio.h>

void lo_up(char a[],char m2[],char M2[]){
int i,m1,M1;
for(i=0,m1=0;a[i]!='\0';i++){
if(a[i]<=122 && a[i]>=97)
{
m2[m1]=a[i];
m1++;
}
}

for(i=0,M1=0;a[i]!='\0';i++)
{
if(a[i]<=90 && a[i]>=65)
{
M2[M1]=a[i];
M1++;
}
}
printf("minusculas:%d maiusculas:%d\n",m1,M1);
printf("MINUSCULAS:%s\n",m2);
printf("MAIUSCULAS:%s\n",M2);
}


int main(void){
char a[140];
char m2[70];
char M2[70];
int k=0;
for(k=0;k<=70;k++) /*FOR DO K*/
{
m2[k]=0;
M2[k]=0;}
printf("STRING:");
gets(a);
printf("STRING RECEBIDA:%s\n",a);
lo_up(a,m2,M2);
return 0;
}
/*OUTPUT DO PROGRAMA SEM O FOR COM K:
STRING:ASDffd
STRING RECEBIDA:ASDffd
minusculas:3 maiusculas:3
MINUSCULAS:ffd¿ü·¤Æü·d׿x׿çÞû·d׿PÆü·
MAIUSCULAS:ASD·«úç·
*/


/*Boas! O código que escrevi supostamente separava maiusculas e minusculas. Depois imprimia minusculas do lado esquerdo e maiusculas do lado direito. Mas esta ***** não fazia nada com jeito lol.Acrescentei akele for com k na função main para incializar os vectores com zero, e assim já deu. Sugiro que copiem o codigo tirem o for e vejam o que acontece, é mt estranho:
1º: Se o gajo quer imprimir o vector tdo pq achou q devia pq e que nao imprime 70 caracteres?
2º O compilador achou q eu nao tinha inicializado o vector pq razao???? Eu inicializeio na função...voces agora pensam: ah mas inicializar na função não e a mm coisa que inicializar depois da linha do main, e eu pergunto: atao mas qual a zona q é supostamente vista pelo compilador como zona de inicialização???
aguardo a vossa ajuda. */

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Isso deve dar um runtime error, porque ao declarares um vector m[70] declaras da posição 0 à 69, m[70] já está fora dos limites.

Ao imprimir os vectores m e M, tens que terminar a string com '\0', caso contrário ele não sabe onde parar.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não dá erro, mas m2[70] vai escrever em M2[0], e M2[70] vai escrever no 1º byte do int k, porque estão declaradas consecutivamente.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Ao imprimir os vectores m e M, tens que terminar a string com '\0', caso contrário ele não sabe onde parar.

Nem mais, e é isso que tu fazes quando usas aquele for... metes todas as posições a 0 (ou seja o caracter '\0') e assim o printf já sabe o que fazer.

Não dá erro, mas m2[70] vai escrever em M2[0], e M2[70] vai escrever no 1º byte do int k, porque estão declaradas consecutivamente.

E como o que tu queres escrever em M2[0] é o mesmo que estás a escrever em m2[70] e o que escreves em M2[70] é o que já tinhas no byte de k (e que é 0), acabas por não ter problemas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Pura coincidência..

Não era isso que ele pretendia fazer no for ao inicializar a 0.

Quando ao M2[0] ser igual ao m2[70], não existe qualquer garantia disso (as variáveis podem ficar espalhadas pela memória, no caso de haver pouca disponível por exemplo).

Se ele está a aprender, não deve  usar este tipo de coisas, funcionem ou não.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Nota que ele não está a usar de propósito. E como são variáveis locais à função, ficam sempre contíguas no stack.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

E como são variáveis locais à função, ficam sempre contíguas no stack.

à partida depende do compilador e da arquitectura. mas as coisa não são assim tão lineares, principalmente quando usas optimizações...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não consigo prever nenhum caso em que todas as variáveis sejam utilizadas e não aconteça o que disse.

Se elaborares, agradeço.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não consigo prever nenhum caso em que todas as variáveis sejam utilizadas e não aconteça o que disse.

Se elaborares, agradeço.

#include <stdio.h>

int main()
{
  int x[4];
  int y[4];
  int n;

  for(n=0;n<5;n++)
  {
    x[n]=10;
    y[n]=20;
  }

  printf("n: %d\n",n);

  for(n=0;n<4;n++)
    printf("%d | %d\n",x[n],y[n]);

  return 0;
}

executa este programa em pc/linux e ppc/macosx e verás resultados diferentes. mesmo usando sempre o gcc com as mesmas flags, num caso (linux) temos as variáveis na ordem y-x-n e noutro caso (mac) temos a variáveis na ordem n-x-y. em mac se usares a flag -O3 a variável n nem aparece em memória (pelo menos é o que o gdb diz, como não conheço o assembly ppc não deu para confirmar no assembly).

lembro-me perfeitamente de quando estava a fazer uma cadeira de arquitectura de computadores ver vários exemplos de códigos em que era perfeitamente visível que a ordem das variáveis não era mantida. penso que quando usavamos a optimização -O2 o compilador ia alocando espaço para as variáveis à medida que as variáveis eram usadas no código, o que leva a que dois programas identicos com as variáveis declaradas na mesma ordem nem sempre tivessem o espaço alocado na ordem que seria de esperar.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Hehe, estudei 3 arquitecturas (ARM, 8051 e x86) e sempre funcionou como disse. Já agora, não trocaste a ordem do x e do y?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Hehe, estudei 3 arquitecturas (ARM, 8051 e x86) e sempre funcionou como disse. Já agora, não trocaste a ordem do x e do y?

não, não troquei, compila o programa e logo vez.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Como já disse, nem é preciso chegar tão longe. Basta não haver memória contígua suficiente, e muda dentro da mesma arquitectura. (neste caso de dois inteiros há sempre, mas se se pretender declarar dois vectores "grandes" por exemplo)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Como já disse, nem é preciso chegar tão longe. Basta não haver memória contígua suficiente, e muda dentro da mesma arquitectura. (neste caso de dois inteiros há sempre, mas se se pretender declarar dois vectores "grandes" por exemplo)

as variáveis locais às funções ficam na stack, logo, tendo em conta os mecanismos de gestão de memória do SO, não devem haver problemas de falta de memória na stack, caso contrário todo o programa pára.

pesno que o "problema" estará relacionado com as optimizações que o compilador tenta fazer...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Hehe, estudei 3 arquitecturas (ARM, 8051 e x86) e sempre funcionou como disse. Já agora, não trocaste a ordem do x e do y?

não, não troquei, compila o programa e logo vez.

Eu acredito. ::P

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