Explicacion del siguiente codigo...

[Olaf "El Blanco"]

/* Ejercicio 1-9. Escriba un programa que copie su entrada a la salida,
reemplazando cada cadena de uno o mßs blancos por un solo blanco. */

#include <stdio.h>
#define IN 1
#define OUT 0

main()
{
int c;
int estado = OUT;
while ((c=getchar()) != EOF) {
if (c != ' ') {
putchar(c);
estado = OUT;
}
if ((c == ' ') && (estado != IN)) {
putchar(c);
estado = IN;
}
}
}


Si c es o no igual a blanco se hace lo mismo...
No se si es que soy un idiota o que!!!
No entiendo...

c es una variable entera... (en teoria, del tamaño de una "palabra") vale no
guardo nada ahi, lo guardo en el buffer del sistema ioperativo... Me olvido
de esto. Pero sigo sin entender...

Otra cosa... ¿Es corercto poner los dos if? o hay que poner el primer if y
luego un else if
si se cumple el primer if, el compilador no va al segundo verdad aunque no
tenga la palabra "else" ???

"IN" le dice que esta dentro de una zona de espacios en blanco... pero no
hace nada...

Lo siento, necesito ayuda....

[McLeod / IdeaFix]

Post by Olaf "El Blanco"
/* Ejercicio 1-9. Escriba un programa que copie su entrada a la salida,
reemplazando cada cadena de uno o mßs blancos por un solo blanco. */
Si c es o no igual a blanco se hace lo mismo...
No se si es que soy un idiota o que!!!
No entiendo...

Lo que hace ese programa es implementar una máquina de estados con dos
estados: IN y OUT. No se hace en absoluto lo mismo cuando c es blanco o no.

- Se empieza en el estado OUT
- Para cada caracter c leído desde la entrada:
- Si c es ' ' y estamos en el estado OUT, se imprime, y se pasa al
estado IN.
- Si c no es ' ', se imprime y pasamos al estado OUT.

Marchando una de arte-ascii cutre para ilustrar la máquina :)

+---- c!=' ' / c --------------+
| |
v |
---> OUT --- c==' ' / c ---> IN ------+
| ^ | ^
| \ | \
| \ | \--+
| \ | \
c!=' ' / c | c==' ' / NADA |
| | | |
+------+ +--------+

En cada transición se especifica: la condición por la que ocurre esa
transición, y lo que se imprime en la salida estándar a resultas de
ocurrir esa transición.

En ambos estados, si se recibe EOF, se pasa al estado final (se termina
el programa)

Los dos IF's son independientes, es decir, se evalúan siempre. No
funciona como un if-else-if.

Una cosa que se deriva de esta máquina de estados, es que si c es ' ' y
estamos en el estado IN, no se imprimirá. Como estamos en IN después de
haber aceptado (impreso) un blanco, todos los que le sigan tendrán IN
como estado y por tanto no se imprimirán, que es lo que queremos. Cuando
terminan los blancos y llega otra cosa que no es un blanco, pasamos a
OUT y todo vuelve a empezar de nuevo.

Post by Olaf "El Blanco"
c es una variable entera... (en teoria, del tamaño de una "palabra") vale no
guardo nada ahi, lo guardo en el buffer del sistema ioperativo... Me olvido
de esto. Pero sigo sin entender...

La entrada estándar se lee en un buffer, y de ahí, a la variable c. Que
c sea un entero y no un char no te lo puedo responder, quizá obedezca a
razones históricas que los señores Kerninghan y Ritchie sabrán :D . Lo
más lógico es pensar que no todo el mundo ni todas las arquitecturas
usan 8 bits para codificar un carácter (mira si no el unicode) y que por
aquella época había cosas como el EBCDIC (en los IBM) que tenían
diferentes longitudes.

De todas formas, si en una determinada implementación de getchar() se
sabe que siempre tomará valores entre 0 y 255, se puede usar sin peligro
un unsigned char, y el casting de C hará el resto (quizás con el
consiguiente warning).

Post by Olaf "El Blanco"
Otra cosa... ¿Es corercto poner los dos if? o hay que poner el primer if y
luego un else if
si se cumple el primer if, el compilador no va al segundo verdad aunque no
tenga la palabra "else" ???

Si se cumple el primer IF, el segundo se evalúa también, aunque sepamos
a priori que no se va a cumplir. En este caso se podría hacer un else-if
para el segundo, pero creo que la lógica del programa se entiende mejor
si se deja como está. No vas a ganar una velocidad apreciable por hacer
una evaluación en lugar de dos.

Saludos,

--
Miguel Angel

[J.A. Gutierrez]

McLeod / IdeaFix <***@quitagmail.estocom> wrote:

: La entrada estándar se lee en un buffer, y de ahí, a la variable c. Que
: c sea un entero y no un char no te lo puedo responder, quizá obedezca a
: razones históricas que los señores Kerninghan y Ritchie sabrán :D . Lo
: más lógico es pensar que no todo el mundo ni todas las arquitecturas
: usan 8 bits para codificar un carácter (mira si no el unicode) y que por
: aquella época había cosas como el EBCDIC (en los IBM) que tenían
: diferentes longitudes.

la razon es mucho mas simple: con 8 bits tienes ocupado
todo el espacio de caracteres pero getchar tiene que ser
capaz de devolver, ademas de todos esos caracteres, la
constante EOF.

Es por eso que tiene que ser un entero.


: De todas formas, si en una determinada implementación de getchar() se
: sabe que siempre tomará valores entre 0 y 255, se puede usar sin peligro
: un unsigned char, y el casting de C hará el resto (quizás con el
: consiguiente warning).

no es correcto.

[Antoine Leca]

no todo el mundo ni todas las arquitecturas usan 8 bits
para codificar un carácter

Cierto.

(mira si no el unicode)

No conozco a ningun compilador C que usa UTF-16 (o UTF-32) para sus char.

y que por aquella época había cosas como el EBCDIC (en los IBM)
que tenían diferentes longitudes.

No. EBCDIC va con carácteres de 8 bits por regla general, y tiene menos
variabilidad en tamaño de almacenimiento que ASCII.

El tamaño de char no era decidido por él de las codificaciones, es al revés:
los codificaciones han usado todos los bits de la unidad básica de
almacenimiento, el byte. Y si esa era de 8 bits para muchos ordenadores de
los 70, se encontraba también la de 9 bits (con los ordenadores con espacio
de direcciones de 36 bits, por ejemplo); y se veo (escasamente) la de 12.
Hoy en dia se encontra también las de 16 bits y 32 bits para algunos DSP.

También hay (hubo) ordenadores con los carácteres almacenados en 7 bits (en
ASCII) dentro de un word de 35+1 bits. Los compiladores C para estas
máquinas usan bytes de 9 bits, que es ilógico si miras al juego de
instrucciones, pero está requirido por las normas de C (necesitas al menos 8
bits para un char).

De todas formas, si en una determinada implementación de getchar() se
sabe que siempre tomará valores entre 0 y 255

getchar() suele poder devolver EOF, que es negativo...
Suponer que getchar() no puede devolver casos de errores es ígual de loco
como usar gets(), en mi opinión.


Antoine