Para Fernando

[Kuky]

Gracias a todos por vuestras respuestas y me queria dirigir a Fernando
ya que he utilizado "su metodo" para la pausa... A ver que os parece
este codigo:

#include <stdio.h>
#define NUM_LINEAS 20

void generar();
void pausa(void);

int main()
{
generar();
}

void generar()
{
float contador = -1;
float n;
float resultado;

do
{
printf("\n Introduce terminos a mostrar: ");
scanf("%f", &contador);

printf("\n");
for (n = 0 ; n < contador; n++)
{
resultado = (2 * n + 1);
printf(" n(%g) = %f\n", n, resultado);
pausa();
}
} while (contador != 1);
}
void pausa(void)
{
static int j = 0;

j++;
if (NUM_LINEAS < j)
{
puts("\n Pulsa una TECLA para Continuar...\n");
getch();
j = 0;
}
}

Es curioso que al ir introduciendo 50 todo el rato, la pausa es bien
distinta ya que no se efectua cada 20 lineas sino que parece al puro
azar... creo q es mejor comprobarlo para entender lo que digo :) A q
creeis que es posible¿ Gracias de nuevo!

[Fernando Arbeiza]

Post by Kuky
float contador = -1;
float n;

Tal como utilizas estas variables, creo que están mejor representados
por un entero (y diría que por un unsigned int).

Post by Kuky
printf("\n Introduce terminos a mostrar: ");

Para que aparezca esto antes del scanf hay que volcar el flujo de
salida. Eso pasa tras un salto de línea pero, como no lo utilizas,
puedes utilizar la función fflush() para que se produzca el volcado:

fflush(stdout);

Post by Kuky
scanf("%f", &contador);

Hay un problema con este scanf(). Seguramente no funcione con el getch()
como esperas. Si después del número introduces un salto de línea,
scanf() tomará el número y dejará en el flujo de entrada el salto de
línea. Luego getch() no esperará la primera vez, porque lee el salto de
línea sobrante.

Mi consejo es que utilices fgets() para leer una línea, y strtol() o
strtoul() (o sscanf()) para leer el número.

Post by Kuky
getch();

Utilizas getch() y, como ya han comentado en otro hilo, no está
declarado en stdio.h. Tienes que incluir la cabecera dos.h (creo) o
curses.h según el sistema en el que lo utilices.

Post by Kuky
Es curioso que al ir introduciendo 50 todo el rato, la pausa es bien
distinta ya que no se efectua cada 20 lineas sino que parece al puro
azar...

No, no es al azar. Pero tienes que entender la variable static que
aparece en la función pausa. La variable static guarda su valor entre
llamadas a la función. Luego si pides 50 términos, el programa mostrará
21, 21 y 8. Pero la variable static tendrá el valor 8, luego la
próxima vez que pidas 50 términos se mostrará el resto (13) de los
términos y después 21 y 16 términos.

Espero haberme explicado.

[Martin J. Sanchez]

On Wed, 14 Jan 2004 23:12:14 +0100, Fernando Arbeiza

Post by Fernando Arbeiza
...

Post by Kuky
printf("\n Introduce terminos a mostrar: ");

Para que aparezca esto antes del scanf hay que volcar el flujo de
salida. Eso pasa tras un salto de línea pero, como no lo utilizas,
fflush(stdout);

Post by Kuky
scanf("%f", &contador);

Cuando una salida a stdout va seguida de una entrada (stdin), el flush
es implicito, siendo innecesario realizar un fflush.

Post by Fernando Arbeiza
Hay un problema con este scanf(). Seguramente no funcione con el getch()
como esperas. Si después del número introduces un salto de línea,
scanf() tomará el número y dejará en el flujo de entrada el salto de
línea. Luego getch() no esperará la primera vez, porque lee el salto de
línea sobrante.

Aunque en efecto se queda el \n en la stream de stdio. getch() no usa
la stream y coge directamente del buffer de teclado del sistema
operativo.

Un saludo,
Martin.

[Fernando Arbeiza]

On Tue, 20 Jan 2004 15:57:51 +0100, Martin J Sanchez

Post by Martin J. Sanchez

Post by Fernando Arbeiza
fflush(stdout);

Post by Kuky
scanf("%f", &contador);

Cuando una salida a stdout va seguida de una entrada (stdin), el flush
es implicito, siendo innecesario realizar un fflush.

_puede_ ser innecesario. El estándar no lo asegura, luego no tiene por
qué cumplirse en todas las implementaciones. Lo más portable sería
utilizar el fflush.

Post by Martin J. Sanchez

Post by Fernando Arbeiza
Hay un problema con este scanf(). Seguramente no funcione con el getch()
como esperas. Si después del número introduces un salto de línea,
scanf() tomará el número y dejará en el flujo de entrada el salto de
línea. Luego getch() no esperará la primera vez, porque lee el salto de
línea sobrante.

Aunque en efecto se queda el \n en la stream de stdio. getch() no usa
la stream y coge directamente del buffer de teclado del sistema
operativo.

Ah, gracias. Lo estaba mezclando con getchar(), con el que sí se tiene
ese problema.

Un saludo.

[Martin J. Sanchez]

On Wed, 21 Jan 2004 00:58:07 +0100, Fernando Arbeiza

Post by Fernando Arbeiza
On Tue, 20 Jan 2004 15:57:51 +0100, Martin J Sanchez

Post by Martin J. Sanchez

Post by Fernando Arbeiza
fflush(stdout);

Post by Kuky
scanf("%f", &contador);

Cuando una salida a stdout va seguida de una entrada (stdin), el flush
es implicito, siendo innecesario realizar un fflush.

_puede_ ser innecesario. El estándar no lo asegura, luego no tiene por
qué cumplirse en todas las implementaciones. Lo más portable sería
utilizar el fflush.

Del estandar:

7.19.3.3
When a stream is line buffered, characters are intended to be
transmitted to or from the host environment as a block when a new-line
character is encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer is
filled, when input is requested on an unbuffered stream, or when input
is requested on a line buffered stream that requires the transmission
of characters from the host environment. Support for these
characteristics is implementation-defined, and may be affected via the
setbuf and setvbuf functions.

7.19.3.7
...
As initially opened, the standard error stream is not fully buffered;
the standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device.

Como ves, el estandar lo especifica claramente: si stdin y stdout se
refieren a un dispositivo interactivo (no redirigidas a ficheros o
dispositivos de bloque), no estaran totalmente buferadas. Es decir, o
bien no estan buferadas en absoluto o bien estan buferadas por lineas.
Y como ves en el punto 7.19.3.3 esto obliga a que una lectura de
dispositivo provoque un flush de la salida. Sin embargo, el flush es
implicito si se necesita leer datos del dispositivo, no si se esta
leyendo datos que permanecen en el buffer de la stream.

Un saludo,
Martin.

[a***@ono.com]

Hola:

Veo que cada uno leemos lo que queremos ;-) (yo el primero). A mí la

Post by Martin J. Sanchez
7.19.3.3
When a stream is line buffered, characters are intended to be
transmitted to or from the host environment as a block when a new-line
character is encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer is
filled, when input is requested on an unbuffered stream, or when input
is requested on a line buffered stream that requires the transmission
of characters from the host environment. Support for these

^^^^^^^^^^^^^^^^^

Post by Martin J. Sanchez
characteristics is implementation-defined, and may be affected via the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Post by Martin J. Sanchez
setbuf and setvbuf functions.
7.19.3.7
...
As initially opened, the standard error stream is not fully buffered;
the standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device.
Como ves, el estandar lo especifica claramente: si stdin y stdout se
refieren a un dispositivo interactivo (no redirigidas a ficheros o
dispositivos de bloque), no estaran totalmente buferadas. Es decir, o
bien no estan buferadas en absoluto o bien estan buferadas por lineas.
Y como ves en el punto 7.19.3.3 esto obliga a que una lectura de
dispositivo provoque un flush de la salida. Sin embargo, el flush es
implicito si se necesita leer datos del dispositivo, no si se esta
leyendo datos que permanecen en el buffer de la stream.

Lo especifica, pero también especifica que es una característica
"definida por la implementación", luego entiendo que una
implementación puede elegir si implementarlo o no. Para mí, eso no es
lo suficientemente portable ;-)

Un saludo.

[Martin J. Sanchez]

Post by a***@ono.com
Veo que cada uno leemos lo que queremos ;-) (yo el primero). A mí la

Post by Martin J. Sanchez
7.19.3.3
of characters from the host environment. Support for these

^^^^^^^^^^^^^^^^^

Post by Martin J. Sanchez
characteristics is implementation-defined, and may be affected via the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Post by Martin J. Sanchez
setbuf and setvbuf functions.

...
Lo especifica, pero también especifica que es una característica
"definida por la implementación", luego entiendo que una
implementación puede elegir si implementarlo o no. Para mí, eso no es
lo suficientemente portable ;-)

Pues si que lees lo que quieres, si. El estandar dicta claramente como
se comporta stdin. Lo unico que es dependient de la implementacion, es
el SOPORTE (el como se consiga) para obtener ese comportamiento.

Un saludo,
Martin.

[a***@ono.com]

Post by a***@ono.com

7.19.3.3 of characters from the host environment. Support for these

^^^^^^^^^^^^^^^^^

characteristics is implementation-defined, and may be affected via

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

the
setbuf and setvbuf functions.

... Lo especifica, pero también especifica que es una característica
"definida por la implementación", luego entiendo que una
implementación puede elegir si implementarlo o no. Para mí, eso no es
lo suficientemente portable ;-)

Pues si que lees lo que quieres, si. El estandar dicta claramente como
se comporta stdin. Lo unico que es dependient de la implementacion, es
el SOPORTE (el como se consiga) para obtener ese comportamiento.

Creo que lo que estás cometiendo un pequeño error de traducción (estos
ingleses son muy enrevesados ;-). Que algún bilingüe diga si me
equivoco, pero yo diría que con "Support for these characteristics is
implementation-defined" quieren decir que la implementación puede elegir
si soportar esas características o no.

Además, creo que especificar lo que dices tendría poco sentido, pues el
estándar define los comportamientos, y como se implementen siempre será
implementation-defined.

Un saludo.

[Martin J. Sanchez]

Post by a***@ono.com
Creo que lo que estás cometiendo un pequeño error de traducción (estos
ingleses son muy enrevesados ;-). Que algún bilingüe diga si me
equivoco, pero yo diría que con "Support for these characteristics is
implementation-defined" quieren decir que la implementación puede elegir
si soportar esas características o no.

Es un poco absurdo no?
Primero dicen como se comportan los distintos tipos de buffering y
luego tu dices que eso puede ser asi o no.

Lo que te estan diciendo es que la implementacion define que tipos de
dispositivos lleva que esquemas de buffering. Como se comporta el
soporte de setbuf, etc. Pero el estandar el otro apartado, dice como
son los esquemas de buffering de dispositivos interactivos, asi que
que la implementacion solo debe definir si es buferado por lineas o no
buferado en absoluto.

De todas formas, la interpretacion del estandar puede dar lugar a
dudas. Pare ello se suele recurrir a las listas y newsgroups que lo
tratan. Y es lo que yo he hecho mas de una vez.

Por otro lado no me canso de sorprenderme cuando me discutes temas
como este. Estoy seguro que sabes que he estado durantoe años
desarrollando compiladores comerciales tanto de C como de C++.

Un saludo,
Martin.

[Fernando Arbeiza]

On Wed, 04 Feb 2004 17:53:22 +0100, Martin J Sanchez

Es un poco absurdo no? Primero dicen como se comportan los distintos
tipos de buffering y luego tu dices que eso puede ser asi o no.

Pues yo no lo veo absurdo. Primero enumera tres comportamientos
(utilizando el verbo "are intended", lo que ya indica algo):

Furthermore, characters _are intended_ to be transmitted as a block
to the host environment

- when a buffer is filled

- when input is requested on an unbuffered stream

- when input is requested on a line buffered stream that
requires the transmission of characters from the host
environment

Pero acto seguido indica que "support for these characteristics is
implementation-defined", con lo que entiendo que una implementación
puede elegir si utilizar este comportamiento, pero si no lo hace, debe
documentarlo.

Lo que te estan diciendo es que la implementacion define que tipos de
dispositivos lleva que esquemas de buffering. Como se comporta el
soporte de setbuf, etc. Pero el estandar el otro apartado, dice como
son los esquemas de buffering de dispositivos interactivos, asi que
que la implementacion solo debe definir si es buferado por lineas o no
buferado en absoluto.

Tema aparte sería especificar qué considera un dispositivo interactivo,
pero eso es harina de otro costal ;-)

De todas formas, la interpretacion del estandar puede dar lugar a
dudas. Pare ello se suele recurrir a las listas y newsgroups que lo
tratan. Y es lo que yo he hecho mas de una vez.

Tienes toda la razón. Ya que nadie se moja por aquí :-) lo mejor es
pedir una tercera opinión:

<URL: http://tinyurl.com/2t984>

Por otro lado no me canso de sorprenderme cuando me discutes temas
como este. Estoy seguro que sabes que he estado durantoe años
desarrollando compiladores comerciales tanto de C como de C++.

Lo sé, lo sé, y lo respeto; y por ello lo he leído y releído antes de
discutírtelo, y creo que mi interpretación es correcta. Pero como bien
has dicho, es un problema de interpretación (y en un lenguaje que no es
el nuestro), y sé que cuando alguien interpreta algo creyendo que es
correcto, es muy difícil hacerle cambiar de opinión (y mucho más si
tiene experiencia). Y esto le debe de estar pasando a uno de nosotros
dos, puede que tú por tu experiencia, o yo porque soy mu burro ;-DD

Y, aunque te sorprendas, mi opinión es que una discusión (llamémoslo
debate, que es de buena gana); es enriquecedora. Si me he equivocado,
pues se admite, y algo he aprendido en el camino (y quizá alguien más).

Un saludo.

[Fernando Arbeiza]

Post by Fernando Arbeiza
<URL: http://tinyurl.com/2t984>

<URL: http://www.google.es/groups?threadm=40218008.365A1F03%40sun.com>

[Martin J. Sanchez]

Post by Fernando Arbeiza

Post by Fernando Arbeiza
<URL: http://tinyurl.com/2t984>

<URL: http://www.google.es/groups?threadm=40218008.365A1F03%40sun.com>

Ok

Post by Fernando Arbeiza

Post by Fernando Arbeiza
- The fflush(stdout) after printf() is not necessary, since the
standard guarantees that the string is transmitted to the
environment when the input is requested.

No; the transmission is "intended" only if the input is from
(1) an unbuffered stream or (2) a line buffered stream with a
special characteristic.

Primero yo he dicho que no es necesario el fflush si el dispositivo es
interactivo. Y el estandar dicta el comportamiento de buffering de un
dispositivo interactivo:
"the standard input and standard output streams are fully
buffered if and only if the stream can be determined not to refer
to an interactive device."

Y por tanto a un dispositivo interactivo solo le quedan dos
alternativas: o no estar buferada en absoluto o ser buferado por
lineas. Y sobre eso dice el estandar:
"Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer is
filled, when input is requested on an unbuffered stream, or when
input is requested on a line buffered stream that requires the
transmission of characters from the host environment"

Naturalmente que la implementacion dira si stdin y stdout se refieren
a dispositivos interactivos (puede incluso que no haya ningun
dispositivo interactivo en un sistema). Pero es que yo solo me he
referido a la situacion donde stdin y stdout se refieren a un
dispositivo interactivo (un terminal, o consola). Lo demas es sacar
las cosas de contexto.

Un saludo,
Martin.

[Fernando Arbeiza]

On Fri, 06 Feb 2004 14:34:16 +0100, Martin J Sanchez

Post by Martin J. Sanchez
Y por tanto a un dispositivo interactivo solo le quedan dos
alternativas: o no estar buferada en absoluto o ser buferado por
"Furthermore, characters are intended to be transmitted as a block
to the host environment when a buffer is filled, when input is
requested on an unbuffered stream, or when input is requested on a
line buffered stream that requires the transmission of characters
from the host environment"

Te sigues dejando la frase siguiente, y es la que dice que esos
comportamientos no están asegurados: "support for these characteristics

Post by Martin J. Sanchez

- The fflush(stdout) after printf() is desirable, since the
implicit fflush() is not guaranteed when input is requested. It
is not guaranteed because the standard specify that "support for
these characteristics is implementation-defined".

... and that is yet another reason you cannot rely on the automatic
What constitutes an interactive device is implementation-defined.

Luego coinciden en que existen dos razones que impiden que se esté
seguro de que al leer del flujo se produzca un fflush() automático. La
primera es que la implementación puede elegir si implementar o no ese
comportamiento...

Post by Martin J. Sanchez
Naturalmente que la implementacion dira si stdin y stdout se refieren
a dispositivos interactivos (puede incluso que no haya ningun
dispositivo interactivo en un sistema). Pero es que yo solo me he
referido a la situacion donde stdin y stdout se refieren a un
dispositivo interactivo (un terminal, o consola). Lo demas es sacar
las cosas de contexto.

... y la segunda es que una implementación puede decidir si considera a
una terminal o consola lo suficientemente "interactiva" para tratarla

Post by Martin J. Sanchez

What constitutes an interactive device is implementation-defined.
... which means that even if your stdin stream reads from a joystick
or a data glove, the stream could be fully buffered anyhow if the
implementation doesn't consider such devices "interactive."

Un saludo.

[Martin J. Sanchez]

Fernando Arbeiza escribió en mensaje ...

Post by Fernando Arbeiza
On Fri, 06 Feb 2004 14:34:16 +0100, Martin J Sanchez

Post by Martin J. Sanchez
Y por tanto a un dispositivo interactivo solo le quedan dos
alternativas: o no estar buferada en absoluto o ser buferado por
"Furthermore, characters are intended to be transmitted as a block
to the host environment when a buffer is filled, when input is
requested on an unbuffered stream, or when input is requested on a
line buffered stream that requires the transmission of characters
from the host environment"

Te sigues dejando la frase siguiente, y es la que dice que esos
comportamientos no están asegurados: "support for these characteristics

Donde lees tu que esos comportamientos no esten asegurados???? El
estandar especifica claramente el comportamiento de cada tipo de
buffering. Y dice el tipo de buffering que deben tener stdin y stdout:

7.19.3.7
...
As initially opened, the standard error stream is not fully buffered;
the standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device

Ves algun comportamiento no especificado? No es clarito el estandar?:
Un dispositivo interactivo o no esta buferado o esta buferado por
lineas.
Y que conste que aqui siepre estabamos hablando de dispositivos
interactivos (salida y recogida de datos de entradas de usuario por
consola).

En cuanto al párrafo 7.19.3.3. Ahi se habla de las tres modalidades de
buffering y deja muy muy claro su compoortamiento. Estas continuamente
aludiendo a la frase:
"Support for these characteristics is implementation-defined, and
"may be affected via the setbuf and setvbuf functions."

Primero - Una implementacion es libre o no de implementar
n cuanto al Estas continuamente confundiendo: "Unspecified behavior"
(Apendice J.1) con "Implementation-defined behavior" (apendice J.3).

Los "Implementation-defined behaviors", se definen claramente en el
apendice J.3. Toda implementación DEBE documentarlos. Y el único punto
referido al tema que nos ocupa está recogido en J.3.2: -
— What constitutes an interactive device (5.1.2.3).


Un saludo,
Martin

[Fernando Arbeiza]

On Fri, 6 Feb 2004 21:01:41 +0100, Martin J. Sanchez

Post by Martin J. Sanchez
Los "Implementation-defined behaviors", se definen claramente en el
apendice J.3. Toda implementación DEBE documentarlos. Y el único punto
referido al tema que nos ocupa está recogido en J.3.2: -
— What constitutes an interactive device (5.1.2.3).

J.3.12 Library functions

[...]

-- The characteristics of file buffering (7.19.3).

[Martin J. Sanchez]

Post by Fernando Arbeiza
On Fri, 6 Feb 2004 21:01:41 +0100, Martin J. Sanchez

Post by Martin J. Sanchez
Los "Implementation-defined behaviors", se definen claramente en el
apendice J.3. Toda implementación DEBE documentarlos. Y el único punto
referido al tema que nos ocupa está recogido en J.3.2: -
— What constitutes an interactive device (5.1.2.3).

J.3.12 Library functions
[...]
-- The characteristics of file buffering (7.19.3).

En efecto, no de dispositivos interactivos.

Un saludo.
Martin.

[jakala]

buenas tardes!!!

no soy Fernando :P pero tengo mas o menos el mismo gusto que el, en lo que
se refiere al sangrado, al igual que el salto de llaves.

La gente esta acostumbrada a que, cuando hay que poner una llave, dar un
intro
ANTES y DESPUES de la llave. Yo personalmente prefiero no pulsar intro
ANTES de la llave. La llave que cierra la de apertura, la pongo al mismo
nivel de
la funcion que hay en la llave de apertura.

Post by Kuky
#include <stdio.h>
#define NUM_LINEAS 20
void generar();
void pausa(void);
int main(){
generar();
}
void generar(){
float contador = -1;
float n;
float resultado;
do {
printf("\n Introduce terminos a mostrar: ");
scanf("%f", &contador);
printf("\n");
for (n = 0 ; n < contador; n++){
resultado = (2 * n + 1);
printf(" n(%g) = %f\n", n, resultado);
pausa();
}
}while (contador != 1);
}
void pausa(void){
static int j = 0;
j++;
if (NUM_LINEAS < j){
puts("\n Pulsa una TECLA para Continuar...\n");
getch();
j = 0;
}
}

Peronalmente, cuando cierro una llave suelo poner un comentario de que
cierra esa llave, pero SOLO cuando es una llave de funcion.

Otra cosa, PON COMENTARIOS. Al principio parece muy obvio que
NUM_LINEAS < j)... pero luego mas adelante, una comprobacion como
esta no te parecera nada comprensible...

Como te ha dicho fernando, para gustos se hicieron los colores... si te
gusta
esta manera, como si te gusta otra, bien. La cuestion es que este sangrado
y sea "legible".

sobre el tema de que parezca un salto aleatorio... veo que en el codigo de
la
funcion pausa pones como comprobacion (NUM_LINEAS < j)... no seria mayor o
en su caso, igual? :P

otra cosa, este tipo de funcion, no me parece muy "correcto"... a ver que
nos dice
Fernando sobre esto...


Jakala

[Zheo]

A fecha de 15 ene 2004, jakala decidió compartir su precioso tiempo con
los lectores de es.comp.lenguajes.c escribiendo el siguiente mensaje

Post by jakala
buenas tardes!!!
no soy Fernando :P pero tengo mas o menos el mismo gusto que el, en lo
que se refiere al sangrado, al igual que el salto de llaves.
La gente esta acostumbrada a que, cuando hay que poner una llave, dar un
intro
ANTES y DESPUES de la llave. Yo personalmente prefiero no pulsar intro
ANTES de la llave. La llave que cierra la de apertura, la pongo al mismo
nivel de
la funcion que hay en la llave de apertura.

Así lo hago yo ;)

La única salvedad es que yo a veces también pongo comentarios en los
cierre de comillas sin ser funciones (si realmente hay un lío del cagarse)
aunque ahora que lo pienso mejor últimamente no lo hago... :/

Un saludo

[Fernando Arbeiza]

Post by jakala
otra cosa, este tipo de funcion, no me parece muy "correcto"...

Pues no, para algo tan sencillo, con lo que dijo Leto Atreides [1]
bastaba. Hombre, siempre será más bonito guardar los resultados en un
vector y confiar en una función que haga la salida como sea.

[1] Ah, Dune, qué recuerdos.

De todas formas, que no imprima tan /aleatoriamente/ se arregla fácil
(también cambio algunas cosas a como me gusta algo más, no las comento
porque creo que lo hice en el hilo anterior). Ojo, que no compruebo
errores.

/******************/
#include <stdlib.h>
#include <stdio.h>

#define LONG_LINEA 256

#define NUM_LINEAS 20

static void pausa_cada(unsigned int n);

int main(void) {
unsigned int contador;

do {
unsigned int n;
char linea[LONG_LINEA];

fputs("\n Introduce términos a mostrar: ", stdout);
fflush(stdout);
fgets(linea, LONG_LINEA, stdin);
contador = strtoul(linea, NULL, 0);

pausa_cada(0);
for (n = 0 ; n < contador; n++) {
const double resultado = (2 * n) + 1;

printf(" n(%u) = %f\n", n, resultado);
pausa_cada(NUM_LINEAS);
}
} while (contador != 1);

exit(EXIT_SUCCESS);
}

static void pausa_cada(unsigned int n) {
static int j = 0;

if (0 == n) {
j = 0;
return;
}

j++;
if (NUM_LINEAS <= j) {
puts("\n Pulsa ENTER para Continuar...\n");
getchar();
j = 0;
}
}
/******************/

Un saludo.

[Martin J. Sanchez]

Post by jakala
...
ANTES y DESPUES de la llave. Yo personalmente prefiero no pulsar intro
ANTES de la llave. La llave que cierra la de apertura, la pongo al mismo
nivel de la funcion que hay en la llave de apertura.

A mi personalmente este estilo en las llaves de la funcion no me
gusta. Es habitual en programacion java, pero no lo es en absoluto en
programas C o C++.

Post by jakala
...
Otra cosa, PON COMENTARIOS. Al principio parece muy obvio que
NUM_LINEAS < j)... pero luego mas adelante, una comprobacion como
esta no te parecera nada comprensible...

Pero hay que evitar los comentarios cuando el propio codigo se auto
documenta. Los comentarios deben ser suficientes pero no deben
intentar repetir lo que explica el codigo.

Muchas veces he visto codigo que se ha cambiado por depuracion o
mantenimiento, pero se han olvidado actualizar los comentarios. Esto
ademas de molesto, produce graves errores de interpretacion.

Post by jakala
...

Un saludo,
Martin.