Re: pasagem obscura

[Yoshiharu Kohayakawa <yoshi@ime.usp.br>]

Paulo Eduardo A. Silveira writes:
 > Professor, quanto a seguinte passagem...
 > > > 
 > > >        ptr->id = el (j);
 > > >        el (j)->g_entr++;
 > > >        ptr->prox_suc = el (i)->topo_suc;
 > > >        el (i)->topo_suc = ptr;
 > > > 
 > queria saber se a minha interpretacao esta correta:
 > Primeio eh alocada a memoria para um ponteiro de estrutura sucessor

Certo.

 > Depois o id desse ponteiro

ou melhor, o campo id da estrutura do tipo sucessor para o qual aponta o
ponteiro ptr

 > aponta para o endereco de memoria que contem a
 > informacao da estrutura ELS com id = J (ou J - 1, nao importa)...

certo.  Temos que ptr->id vale els+j-1.

 > Depois, o g_entr do ELS de ID=J eh incrementado em um, pois existe um arco
 > que sai de I e vai para J. 

Sim.  Para ser mais preciso, a estrutura que está no endereço ptr-i>id, ou
seja, no endereço els+j-1, tem o seu campo g_entr decremetando de 1.

 > Na terceira linha, 

Nas duas próximas linhas, queremos inserir uma estrutura do tipo sucessor (a
saber, aquela apontada por ptr) na lista de sucessores do elemento i.  Para
ser mais preciso, queremos inserir a estrutura apontada por ptr na lista
ligada cujo primeiro elemento é apontado por el(i)->topo_suc.  

Nesta lista ligada, o campo prox_suc dos seus elementos é usado para apontar
para o próximo elemento desta lista.  Desta forma, as duas instruções
seguintes servem para inserir *ptr (o objeto apontado por ptr) no começo da
lista. 

 > o proximo sucessor do
 > ponteiro, recebe o valor do topo sucessor do ELS com ID=I, ai na quarta
 > linha, o topo sucessor ELS que tem ID=I aponta para esse ponteiro (mas e
 > depois de declarado novamente esse ponteiro com o mesmo nome, nao vai
 > haver conflito ou ele vai alocar outra memoria?)

Estruturas de tipo diferente podem ter campos com o mesmo nome.  Não ocorre
conflito. 

 > Entao pelo que vejo, quando voce escreve el(k), esta querendo dizer o
 > endereco da memoria que aponta para o k-esimo elemnto da estrutura

Sim.

 > encadeada ELS, isto eh, para o elesemnto de ELS que tem seu ELS->ID=K, eh
 > isso ou estou falando baboseiras?

Bem, as estruturas do tipo sucessor estão lá para guardar informação de quem é
sucessor de quem etc.  Eu preciso que cada elemento do tipo sucessor
represente um elemento/tarefa.  Note aliás que várias estruturas do tipo
sucessor representam a mesma tarefa neste sentido---a saber, o número de
estruturas do tipo sucessor que representam j é igual ao número de arcos que
chegam em j.  Neste sentido, talvez seja mais natural pensar que cada elemento
do tipo sucessor representa um arco.

Eu poderia usar o campo id de uma elemento do tipo sucessor para guardar um
inteiro que representa a tarefa j (se o par lido foi (i,j)), ao invés de
guardar o endereço em que está guardado a estrutura que representa aquela
tarefa.  Com um inteiro representando a tarefa, eu teria que fazer a conta
els+(inteiro)-1 para chegar à estrutura que representa a tarefa, para fazer
qualquer coisa com ela (por exemplo, decrementar o contador g_entr dela).
Assim, achei mais natural usar um apontador para a estrutura que representa a
tarefa. 

 > Outra coisa...
 > Quando voce escreve o for de inicializacao do els:
 > 
 > for (ptr = els, k=1; ptr<els + n; ptr++, k++) {
 > 	ptr->id = k;
 > 	...
 > }
 > Eu poderia economizar essa variavel k e escrever da seguinte maneira:
 > for (ptr= els; ptr<els+n; ptr++) {
 > 	ptr->id = ptr - els + 1;

Nao... o que está no lado direito é em unidades de endereço, e portanto teria
que dividir pelo tamanho de uma estrutura... ou algo assim.  

Yoshi 

 > 	...
 > }
 > Iria funcionar nao?
 > Obrigado
 > Paulo