🚀 go-pugleaf

Creo que se esta desvirtuando la pregunta inicial.
Creo que nadie (o pocos) decimos que el GOTO en asm es muy cotidiano. Si
retomamos la pregunta, era que �Que pasa con el GOTO en la programacion en
lenguajes de alto nivel (repito, alto nivel)?

Yo cuando hago un programa, lo intento hacer entendible lo maximo posible.
Esos programas tienen que estar acompa�ados de una documentacion (diagramas
de flujo, comentarios, etc). El dia de ma�ana, habra otra persona encargada
de ese programa, o puedo ser yo mismo. Bueno, si el programa tiene 1 o 2 o 3
Gotos bien documentados y son como los que habeis puesto de ejemplos, creo
que no habria ningun problema (a lo mejor alguna que otra cara malumorada),
pero .. �Que pasa si ese codigo tiene gotos que no tienen ni pies ni
cabeza?, Vamos de los que en organigramas cruzan lineas a saco.... No se si
me entendeis.
Yo hago un organigrama y fale, lo hago como me sale de las pelotas.. Luego a
la hora de codificar flipo y me saco de la manga unos cuantos gotos, los
documento y a tomar por culo, es eso diplomatico, profesional?

La discusion del GOTO la plante� en un principio como �un problema a la hora
de programar? (siguiendo lo que estoy diciendo).

Fale que en programacion nada se complementa por si solo. Todos sabemos que
un goto en situaciones claras y obvias nos puede ayudar a no pensar
demasiado, pero que pasa en estas otras situaciones? Abusar del goto esta
bien, aun cuando las situaciones son numerosas y claras?, O mejor me lo
curro un poco e intento sacar el codigo claro y estructurado para el que
venga detras.

Espero haber aclarado el hilo de la pregunta, debido a ke he observado la
variacion de la pregunta original.


--
Miguel A. Fuentes
tatoflis@wanadoo.es

IF Condici�n = TRUE
      GOTO <El jefe quiere hablar contigo...>
--
Pedro Maicas <www@direccion.es> escribi� en el mensaje de noticias
4omd1toikcik7gsm6d0c6jfu9jnken815u@4ax.com...
> On Sat, 18 Nov 2000 12:47:19 +0100, "David" <davidrodrNOS@PAMexcite.es>
wrote:
>
> >> Es imposible programar en ensamblador sin usar saltos incondicionales
> >(jmp)
> >
> >En absoluto.
> >...........
>
>    Cuando traduces un while o un for a asm, supongamos que
> la comparacion va al principo del bucle, entonces al acabar
> las instrucciones del bucle tienes que poner forzosamente un
> jmp para volver al principio.
>
>   while(condicion){
>     instrucciones;
>   }  <----- Aqu� va un jmp en asm
>
>    Cuando traduces un  if ... else, si hay instrucciones
> que se han de ejecutar en el if y otras en el else, es inevitable
> poner jmp
>
>   if (condicion){
>     instrucciones
>   }
>   else{     <----- Aqu� va un jmp en asm
>     instrucciones
>   }
>
> >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
>
>   Estoy segur�simo de que Ciriaco no dir�a que hay que programar sin
> usar jmp, y tampoco dir�a que los saltos condicionales no son el
> equivalente a un goto.
>
>   Si lo dijese Ciriaco, que no lo dice, tampoco ser�a cierto.
>
>
> >> 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?
>
>   Seg�n t�, en el antiguo basic:   IF condicion THEN  numerolinea
> � eso no es un goto ?  �solo porque es condicional ?  � amosy� !
>
>   Las instrucciones de la programacion estructurada se traducen al
> asembler convirtiendo el programa en no estructurado, obviamente.
>
>   Un while, por muy estructurado que sea, cuando se traduce a asm
> queda como el ejemplo de lo que nunca se debe hacer (de lo que
> nunca se debe hacer en C, pero que en asm es inevitable).
>
> Esto es estructurado:
>
>   while(condicion){
>     instrucciones;
>   }
>
> Y esto no:
>
> ini_bucle:
>   if(!condicion) goto fin_bucle;
>   instrucciones;
>   goto ini_bucle;
> fin_bucle:
>
>   Estas dos porciones de c�digo se traducen a asm exactamente igual,
> el resultado en asm se parece m�s a lo segundo, claro. Y es que
> en asm no se puede programar sin saltos, porque no hay otra cosa que
> saltos. El asm no es un lenguaje estructurado, y que compiles
> un lenguaje estructurado no va a conseguir que el asm "se estructure".
>
>   Yo creo que los que son tan 'integristas' en esto de goto han
> olvidado el fondo del asunto y se han quedado en la forma. Por
> ejemplo, todo el mundo echa pestes porque en visual basic
> existe la instruccion 'or error goto xxxx', solo porque ven
> ah� la palabra goto, cuando esa instruccion tiene poco
> que ver con un goto, es un tratamiento de excepciones,
> seguro que si se escribiera  catch error xxxx  nadie se quejar�a.
>
>   Incluso en los gotos de verdad, muchas veces es m�s facil
> seguir la l�gica del programa usando un goto en una funcion,
> tambien es m�s facil de mantener para una persona distinta a la
> que escribi� el programa. Un goto bien usado, siempre que se vea
> claro a donde va, puede simplificar mucho el aspecto del programa
> (que al fin es lo que cuenta cuando te pones a tocar c�digo de otro).
>
>   Por ejemplo:
>
> funcion()
> {
>     obtiene recursos;
>     ........
>     if(loquesea) goto salida;
>     ........
>     if(loquesea) goto salida;
>     ........
>     if(loquesea) goto salida;
>     ........
>     if(loquesea) goto salida;
>
> salida:
>     libera recursos;
> }
>
>    Cuando ah� metes muchas instrucciones y la funcion es grande, est�
> mucho m�s claro con el goto que la version estructurada (un monton
> de ifs anidados dentro de otros ifs), sobre todo porque hay un
> �nico destino de todos los gotos y porque el nombre de la etiqueta
> es lo suficientemente descriptivo. En este caso el nombre elegido
> para la etiqueta es m�s importante que ninguna otra cosa, porque
> simplifica enormemente seguir el flujo del programa.
>
>    Lo mismo se aplica a la salida de una serie de bucles anidados,
> claro que se puede hacer sin goto, pero eso �simplifica el programa
> o lo complica ?   si lo complica que cada uno saque sus conclusiones.
>
>    Adem�s no comprendo a los que dicen que un profesor le
> dijo que un goto no se usa nunca (y encima ponen el nunca en
> mayusculas). Seguramente el profesor no confiaba mucho en el
> sentido comun de los alumnos y se cur� en salud, a lo mejor
> ten�a raz�n el profe porque yo tampoco me fiar�a del que no
> encuentra argumento mejor que el argumento de autoridad. A
> mi me lo puede decir san pedro, si veo que el programa queda
> m�s claro con un goto no lo dudo ni un momento.
>
>    Luego tampoco tiene mucho sentido que un integrista del
> goto, que se supone debe ser un maestro en hacer c�digo
> entendible, le ponga de nombre a una funcion 'funcion',
> o te cree una funcion de trescientas lineas y diez niveles
> de anidamiento que no hay quien la entienda. O bien que
> no te pongan un comentario, y los pocos que ponen son
> de esta guisa:
>
> funcion()
> {
>   int i;
>   i = 0;  file://inicializo i a cero
>
>   Aaaaa, ya, vale, pero sobre todo no uses un goto NUNCA.
>
>   Por cierto, esto es un crossposting bestial, aunque supongo que est�
> dentro del tema de todos los grupos. Ya puestos a hacer algo m�s que
preguntar
> y responder (yo tambien opino que esto es m�s util y m�s entretenido) creo
> que podr�amos abrir otro crossposting sobre c�mo hacer el c�digo m�s
> facilmente entendible/mantenible.
>
>
>
> Saludos :-)           -Pedro-
>
>   Maicrosoft LVP
>
>   http://www.maicas.net/
>
>   e-mail en www.maicas.net