#30 ahí le has dado, tambien lo dijo MTX_Anubis
Por ahi he leido algo de que continue y break son lo mismo...
El continue salta al principio del corchete/bloque actual ( En el caso de whiles eh ! )
while {(1) ....{..}.... continue; ...{..}.. } -> te llevaria a (1)
while {(1) .... {..} ... {(2) ... continue ; ...} .... } -> te llevaria a (2)
Y el break te lleva al final del corchete actual.
while { ....{..}.... break; ...{..}.. }(1) -> te llevaria a (1)
while {(1) .... {..} ... { ... break; ...}(2) .... } -> te llevaria a (2)
Por lo que un : if (...) { continue; } , no hace nada. Mientras que un if (...) continue; Si.
#24, los gasté el año pasado y no me acuerdo bien de como usarlas, pero tienes mutex y semáforos, y alguna que otra clase por ahí un poco más especializada, por ejemplo la mutexlocker, que cuando se llama al constructor bloquea un mutex y cuando se destruye lo desbloquea, para casos en los que tienes un puñado de if's anidados en los que puedes salir de la función en uno de ellos, no tengas que poner el código para desbloquearlo antes de cada return.
La documentación de Qt está muy muy bien, échale un ojo. Y Qt no solo sirve para hacer GUIs (de hecho, puedes no enlazar con la parte gráfica).
Yo por este foro siempre termino diciendo lo mismo.
Blkz, existe mas mundo alla de los pcs. Existen multitud de aplicaciones donde el tiempo es critico, y un break/continue es muchas veces es mas necesario y eficiente.
No existe un unico standar de como hacer las cosas, meteoslo en la cabeza, ahi teneis como ejemplo a #28.
Un ejemplo incluyendo break.
Imaginemos que leemos un archivo de texto carácter a carácter
hasta encontrar el final de fichero o una de las siguientes letras: 'a', 'p', 'q', 'x'.
Dependiendo de la letra quiero poner una variable a un valor concreto antes
de parar de leer. Sólo quiero hacerlo para caracteres alfanuméricos
de modo que debo saltarme los demás.
En todos los demás casos (todas las demás letras) quiero imprimir el carácter actual leído.
A bote pronto (sin testear ni nada) yo lo haría de la siguiente manera:
char ch;
int valor;
while(!feof(pfile))
{
c = fgetc(pfile);
// No es alfanumerico, pasemos al siguiente.
if(!isalpha(c)) continue;
// Comprobamos posibilidades y asignamos si cuadra con la letra.
if(c == 'a') { valor = 1; break; }
if(c == 'p') { valor = 5; break; }
if(c == 'q') { valor = 6; break; }
if(c == 'x') { valor = 9; break; }
// En todos los demás casos sólo imprimo.
printf("%c", ch);
}
Creo que es la forma más clara y concisa.
Quizá también más eficiente. Este algoritmo no necesita eficiencia... pero para el ejemplo
imaginaremos que sí, como antes.
¿ Alguna alternativa ?
Saludos. : -)
El problema es que aunque en este caso el if y la asignación no importan...
en otros como en el intérprete de un lenguaje que luego correrá miles de programas sí.
Edit: Por cierto... me suena : -P
Yo nunca he dicho lo contrario. Si quieres (o necesitas por eficiencia) programar en C (o el que sea) a base de saltos como si fuera ASM pues tira millas, pero no lo llames programación estructurada porque no lo es. Simple, sencillo y para toda la familia.
Salu2 
100% de acuerdo
||
||
\/
La programación estructurada no es una regla escrita en fuego que haya que seguir sí o sí o mueres.
Es un conjunto de buenas prácticas que busca evitar los problemas que surgen de escribir código "sobre la marcha" sin ningún tipo de diseño ni planificación.
En concreto lo que se busca es que se produzcan algoritmos fáciles de entender, y fáciles de mantener.
No seguir una regla de la programación estructurada, ni es malo, ni es un error, siempre que produzcas un código fácil de entende y de mantener.
¿Quieres un ejemplo de algo que se salta las normas de programación estructurada y no está considerado mala práctica?
try
{
loquesea();
}
catch(Excepcion tal)
{
}
catch(Excepcion pascual)
{
}
catch(Excepcion generica)
{
}
En programación estructurada no se permite saltos del flujo de ejecución de un punto a otro, y eso es lo precisamente lo que hace la estructura try catch que se usa para el control de excepciones.
Más que memorizar reglas y pensar que es obligatorio seguirlas pase lo que pase, es mejor entender por que existen esas reglas, que objetivo tienen, y cuando te las puedes saltar sin que sea algo malo.
Si te encuentras en una situación en la que ves que no sigues al pie de la letra la programación estructurada, en lugar de entrar en pánico y saltar por la ventana, evalua que que te supone saltarte esa norma, y que te supone cambiar el código para seguirla, y teniendo como punto de referencia la claridad, simplicidad, y mantenimiento fácil, elige la mejor de las dos.
Acabo de empezar un proyecto en el curro bastante complejo q me llevará un par de años por lo bajo terminarlo y lo siento, en el diseño no me preocupo si un for se rompe con un break (ahora mismo recuerdo q tengo 2 breaks q rompen 1 for en el código), sino de como implementar el sistema para que cuando hayan 382938012 comunicaciones a la vez de forma asíncrona, envíandose paquetes y esas cosas, sea estable, rápido y eficiente.
Cuando el producto vea la luz, los clientes lo comprarán si cuando le den a tal botoncito salte esa magia de manera rápida y sencilla para ellos.
En resumen, cuando tu código tiene miles y miles de líneas, no te pierdes al seguirlo por cosas como breaks con for precisamente xDDD.
A mi me parece peor cuando tienes en un hilo una clase q esa clase está derivada de otra q a su vez hereda de otra q coge el método sobrecargado de la primera, q luego tiene un evento blablablabla.....cosas, q luego para seguirlas son imposibles.
A mi me parece muchísimo peor el q tiene lenguajes de programación orientado a objetos por delante y los usa como si fueran estructurados, pero bueno.
Yo no se pq os olvidais siempre de los que programamos empotrados xD
Romper bucles es de lo mas normal del mundo, donde saltarse "un par de instrucciones" equivale a mas autonomia (hablando de consumo) y mas recursos.
Pues si vierais algunos drivers de Linux, que llevan incluso gotos. Lo que pasa es que para programar rutinas de interrupción y cosas de tan bajo nivel, muchas veces te tienes que salir del bucle o de un puñado de if por un error y esa es la manera más fácil de hacerlo.
Linus Torvalds acerca de "goto", "break", código estructurado y tal en el kernel de linux.
http://kerneltrap.org/node/553/2131
Que genialidad de discusion.
Me quedo con lo siguiente:
We keep lowering the bar for technical prowess, it seems; if something has
the potential to be used "wrong", high-minded designers remove the offending
syntax rather than find or train competent programmers. This is why Java
removes pointers (among other things) -- it's not that pointers aren't
useful or efficient, it's that they require discipline from programmers.
Lo que se resume de la discusión, es que el goto en si no es ni malo ni bueno, todo depende del programador si es bueno o no, y esta gente parece ser que "sabe un poquito" xD. Si el programador no es bueno, todo lo que sea potencialmente de hacerse un mal uso, se va a hacer. Y el goto tiene todas las papeletas, seguido de punteros y demas stuff.
Basicamente dicen, que con unas labels claras, el goto es muchisimo mejor para leer codigo de una manera mas facil y rapida (estan hablando del kernel de linux), que condiciones anidadas en mas condiciones (2 condiciones son faciles de ver, pero... y si tengo 30?), lo cual lo que hace es que al final nadie se entere de nada.
Un break y un continue son lo mismo, son saltos incondicionales. Ambos pueden reemplazarse por la misma setencia, un goto label. El label en break y continue esta implicito, pero no por eso dejan de ser lo mismo.
goto inicio bucle; (continue)
goto final+1 bucle; (break)
goto adondetuquieras;
