🚀 go-pugleaf

retomando el hilo de esta anzestral diskusi�n, lo m�s interesante es ver
komo el tema, aun hoy en d�a, levanta ampollas, induce a la hilaridad y/o
produce sarpullidos y espasmos :-)

Amos a ver, assembler, que yo sepa (y no soy un experto en asm) no permite
condicionar "bloques" de c�digo. eso hace inevitable el uso de etiquetas (o
direcciones) y saltos a las mismas. El resultado es una ensalada de saltos y
etiquetas y ESO, precisamente eso, es lo que tiene de malo el GOTO : ke
tiende a producir ensaladilla de c�digo.

El goto en s� es de lo m�s inocente, y en la mayor�a de lenguajes existen
estructuras de control alternativas para condicionar bloques de c�digo. No
as� en asm, ahi se tira de goto por narices, y en ese sentido tiene toda la
raz�n Pedro Maicas al decir que jc, jnc y jmp son la misma kosa: un goto
mondo y lirondo.

El problema de base no es el goto, sino que el destino de un goto (salto)
siempre es fijo, y su ubicaci�n apenas puede validarse desde el punto de
vista del compilador o int�rprete. Si se abusa de este tipo de saltos, el
c�digo puede resultar bastante ilegible. Por contra, un bucle for() o do(),
un constructo if()else o case, son patrones de estructura de control
claramente definidos, se sabe perfectamente c�mo se comportan, se VE el hilo
de ejecuci�n a simple vista : los DESTINOS de los saltos est�n claros y son
intuitivos, tienen un �mbito delimitado y, sobre todo, no hace falta
explicitarlos (las dichosas etiquetas). Por lo dem�s, un compilata s� puede
adevrtir si un for() o do() por ejemplo est�n bien formados o no. Osea, para
el uso diario, nada mejor que un for() :-D

Anyway, no creo que valga la pena ser tan estricto como algunos predic�is.
He visto casos en que el uso de un (un!) goto puede resultar muy pr�ctico, e
incluso elegante, seg�n se mire. Y repito, lo que ofusca el c�digo no son
tanto los gotos como los destinos. Por ejemplo, un c�digo como �ste :
    ...
    if (lokesea) goto alpeo;
    ...
    if (lokesea) goto alpeo;
    ...
alpeo:
    liberarloToo() ;
    return ;

Un c�digo asi puede tener 500 gotos, pero todos son el mismo escape a una
salida controlada. Claro, sencillo y robusto. Por su puesto, hay otras
muchas formas de expresar lo mismo pero ... alguien realmente puede decir,
kon el coraz�n en la mano (chorreando sangre, eeeks!), que �sta forma esta
MAL? Porqu�?

Mientras tanto, ya me parece bien que a los estudiantes de inform�tica les
digan en primero ke el GOTO es la ENKARNAZI�N MISMA DEL MAL, ke yuyu-yuyu si
lo usan y ke areder�n en el infierno y se ir�n al paro de kabeza y se les
kaer� la piel a tiras. (Pero por el mismo precio les podr�an advertir
tambien contra la modulitis, layeritis, objetitis, formalitis,
multiplataformitis y otras muchas infecciones algor�tmikas que producen
c�digo guarro por ah�.) Luego, un poko m�s relajados y cuando hayan hecho 1
o 2 programas serios, ya descubrir�n ke despu�s de todo no es tan malo y,
komo todo, tiene sus aplicaciones y su sitio.

pos eso
saludos
goto alBar


"David" <davidrodrNOS@PAMexcite.es> escribi� en el mensaje
news:8v5q8s$jb2$1@titan.bt.es...
> Hola Pedro
>
> "Pedro Maicas" <www@direccion.es> escribi� en el mensaje
> news:vpoa1tc0cg7go25021sfiajav8p4qa5e1v@4ax.com...
> > Es imposible programar en ensamblador sin usar saltos incondicionales
> (jmp)
>
> En absoluto.
> Estoy de acuerdo con que es mucho m�s f�cil encontrar saltos
incondicionales
> en un programa en ensamblador que en uno en lenguaje de alto nivel. Pero
su
> uso es totalmente evitable. Por ejemplo, si quieres saltar a fin_proc si
el
> resultado de la �ltima operaci�n ha generado un acarreo y, si no, tienes
que
> saltar a cont_proc, puedes escribir:
>
> ...
> jc fin_proc
> jmp cont_proc
> ...
>
> Pero esto es totalmente evitable. Lo correcto hubiera sido escribir:
>
> ...
> jc fin_proc
> jnc cont_proc
> ...
>
> Pero bueno, se ahorran ciclos al evaluar el flag de acarreo y tal (aunque
el
> tiempo perdido aqu� es una minucia, comparado con otros tiempos de
espera).
>
> Si vas a http://udigital.homepage.com/libro/src/dmap.html te encontrar�s
con
> un programa en C y ensamblador (realizado por el, en mi opini�n, mejor
> programador en ensamblador que he conocido, Ciriaco Garc�a de Celis, Ciri
> para los amigos), en el que s�lo te encontrar�s con 2 jmps en la parte en
> ensamblador. Casualmente, estos jmps son de los que mencionaba antes como
> 'evitables'. Por supuesto, no te encontrar�s con ning�n goto en la parte
en
> C :-)
>
> > Adem�s un salto condicional es 'tan goto' como como uno incondicional.
>
> �Einnn? �Norrrrrl!. Nabsoluto. �Tas de co�a? Con eso me est�s diciendo que
> un for, un do-while o un while (incluso un if) no son m�s que gotos
> maquillados. Si no �c�mo se traducen a ensamblador estas estructuras de
> control?
>
> > Saludos :-)           -Pedro-
>
> Saludos. Sigue el hilo, que me est� molando est� discusi�n. No es broma,
la
> defensa / criminalizaci�n del uso del goto es una controversia muy fuerte.
> Hay ayatollahs en ambos bandos, y convencernos mutuamente va a ser
> virtualmente imposible, pero �y lo que se puede aprender?
>
> Como curiosidad, te dir� que 'goto' es una palabra clave reservada en
java.
> Sin embargo, no aparece como estructura de control por ning�n lado.
> �����?????
>
> Y yo, lo m�s parecido a 'goto' que he utilizado en mi vida como
programador
> (salvando aquellos tiernos tiempos en que programaba en Basic) es el
> 'gotoxy' de Pascal. Y no tiene nada que ver con lo que estamos hablando,
> pero ya desvar�o.
>
> De nuevo, saludos y, �por qu� no? un abrazo
>
> David
>