[feriva]

Sin embargo, por lo que veo por tus dudas, es menos intuitivo, ya que la comparación no se hace IN SITU, sino antes, y no se ve claramente que estamos interesados en el resultado de dicha comparación.

No, no es por eso, eso lo entiendo, entiendo todo menos el funcionamiento de esa constante; de hecho he variado el programa así para que aparezca la ventana Windows (y me funciona bien):


#define Me_Conformo_con_CMD  1
#define Me_Gusta_mas_Windows 0

#define Creo_que Me_Conformo_con_CMD

#define Creo_que Me_Gusta_mas_Windows

#define CMD_OK (Creo_que == Me_Conformo_con_CMD)
#define WIN_OK (Creo_que == Me_Gusta_mas_Windows)

#if CMD_OK
   #include <stdio.h>
   #define Mostrar_INFO_CMD(S) ( printf(S), getchar(), 0)   
#elif WIN_OK
   #include <windows.h>
   #define Mostrar_INFO_WIN(S) ( MessageBox(NULL,S,"Info",0), 0)
#else
   /* Nada */
#endif

#define Mostrar_INFO(S) \
   (CMD_OK? Mostrar_INFO_CMD(S): \
      (WIN_OK? Mostrar_INFO_WIN(S): (0)) )

void main(void) {   
   Mostrar_INFO("Hola Mundo!!\n\n") ;
}


Pero me sigue extrañando la sintaxis, y también me extraña que el microprocesador sepa que es una constante y no una variable; ¿debo entender que #define es una instrucción para definir constantes exclusivamente y existe otra distinta para definir variables?  No obstante, no pasa nada, si es así como  entiende este comando el microprocesador, es así y ya está; queda visto y asimilado.

 

[feriva]

Ahhh, si es que no le has puesto paréntesis, por eso no le entendía

Es esto #define (Creo_que) (Me_Gusta_mas_Windows) Es decir, carga el valor de

Me_Gusta_mas_Windows (o la opción que sea) en Creo-que.

 Parecía todo una sola cosa, no lo veía, ahora sí.

[argentinator]

La cláusula #define no sabe nada de constantes o variables.

En realidad lo que único que hace es definir reglas de sustitución de porciones de texto.

Lo que hace es intentar hacer las distintas sustituciones, hasta que ha revisado todas las macros declaradas con #define.

Eso es lo que hace el preprocesador.

A continuación, el compilador toma el código resultante que le dejó el preprocesador y se fija si hay constantes, y trata de evaluarlas.

La cuestión es que todos los valores que uno escribe a mano, como 5.14, "piribim", "Hello World", 0.0, etc., son constantes, y el compilador sí que reconoce que son constantes y no variables.

Las variables son identificadores que han de declararse en alguna parte como tales, y el compilador también es capaz de reconocer esto, claro.

Pero más aún, si en una expresión en la que hay operadores de C, los operandos son sólo constantes, el resultado es calculado y evaluado directamente por el compilador, y entonces ese resultado es lo único que realmente queda.

El efecto es que queda un código equivalente a que si nosotros hubiéramos escrito el resultado del cálculo a mano, en nuestro propio programa fuente.

Esto tiene sentido, porque es un valor que no va a cambiar durante la ejecución del programa, y entonces no hay inconveniente en que el compilador se tome el atrevimiento de precalcular todo, antes de realizar la compilación "definitiva" del programa.

____________


Lo que hay que entender es que el proceso de compilación se hace en realidad en varias etapas,
y en cada etapa se hace alguna que otra operación de traducción.

Todas esas traducciones consisten en convertir nuestro código fuente en otros programas equivalentes en C, pero que "no se ven".
Si pudiéramos ver el resultado de estos procesos, veríamos programas en C parecidos a los nuestros, salvo que con algunos cambios debido a que ya se han cumplido algunos preprocesos.

____________

En cuanto a tus cambios de números:

#define Me_Conformo_con_CMD  1
#define Me_Gusta_mas_Windows 0

no tienen importancia.

Justamente el código está pensado para que uno pueda poner ahí los números que se le antojen, y todo funcione al final como se espera que tiene que funcionar.

El único requisito es que ambas constantes tengan un valor numérico y distinto.

Esto no lo hemos verificado, pero puede hacerse, e incluso hacer saltar el compilador informando de un mensaje de error en caso de que no se cumpla...

______-

Otra cosa que veo en tu código son las 3er y 4ta líneas:

#define Creo_que Me_Conformo_con_CMD

#define Creo_que Me_Gusta_mas_Windows

Si realmente tenés esas dos líneas escritas, está mal, porque estarías anulando con la segunda la definición que hiciste con la primera.

Entonces siempre te quedará el efecto de la ventanita en Windows como resultado.

Sólo se puede dejar una sola de esas dos líneas.

[argentinator]

Es esto #define (Creo_que) (Me_Gusta_mas_Windows) Es decir, carga el valor de

Eso así está mal, no se le pone un paréntesis al primer identificador "Creo_que".

En cambio está bien, y es aconsejable hacerlo, con el segundo, así:

#define Creo_que (Me_Gusta_mas_Windows)

Y sí, es lo que vos decís.
No me dí cuenta que se podía ver todo muy "pegoteado".

[feriva]

Es esto #define (Creo_que) (Me_Gusta_mas_Windows) Es decir, carga el valor de

Eso así está mal, no se le pone un paréntesis al primer identificador "Creo_que".

En cambio está bien, y es aconsejable hacerlo, con el segundo, así:

#define Creo_que (Me_Gusta_mas_Windows)

Y sí, es lo que vos decís.
No me dí cuenta que se podía ver todo muy "pegoteado".

Todo entendido; todos los errores eran por la sintaxis.

 O sea, para ver si lo he entendido de verdad, el lenguaje C interpreta #define variable (argumento) siempre que se deje un espacio aunque no se pongan los paréntesis, y de ahí que utilices guiones bajos para no separar el nombre de las variables (cuando digo variable, sí, me refiero a "variable a mano" o "constante elegible", claro).

Saludos.   

[argentinator]

Claro, la función del los guiones bajos es esa.

Hay gente que ni los usa, y pone mayúsculas para indicar nueva palabra, así:

CreoQue

En cuanto a la terminología adecuada... no es ni variables, ni constante a mano, jejeje.

Yo diría que hay que usar el término "identificador".

Las "constantes a mano" no son identificadores, porque no son nombres de nada,
sino que son valores explícitos de algún tipo, ya sea números, caracteres, cadenas de caracteres, etc.

[feriva]

Claro, la función del los guiones bajos es esa.

Hay gente que ni los usa, y pone mayúsculas para indicar nueva palabra, así:

CreoQue

En cuanto a la terminología adecuada... no es ni variables, ni constante a mano, jejeje.

Yo diría que hay que usar el término "identificador".

Las "constantes a mano" no son identificadores, porque no son nombres de nada,
sino que son valores explícitos de algún tipo, ya sea números, caracteres, cadenas de caracteres, etc.

Comprendo, #define viene a ser parecida a al comando "def fn" del antiguo Basic.

Gracias, Argentinator.

[argentinator]

Comprendo, #define viene a ser parecida a al comando "def fn" del antiguo Basic.

Es posible, no me acuerdo muy bien de Basic.

Pero el olfato me dice que no son análogas del todo.

Lo importante acá es recordar que las directivas del compilador, que empiezan con el signo #,
efectúan transformaciones a nuestro programa antes de crear el ejecutable.

Todo lo que hace el #define, lo hace en etapas de compilación, dejando todo precalculado,
y así esas operaciones, asignaciones y transformaciones no tienen lugar cuando ejecutamos la versión ejecutable del programa, que no se entera de nada.

Es decir, hay aspectos de los programas en C que no inciden en el programa ejecutable definitivo, sino que se resuelven antes, una única vez, durante el proceso de compilación.

Estas tareas de gestión es necesario comprenderlas, aunque sea de a poco.
He puesto estos ejercicios a propósito para aprender estas cosas.

[feriva]

Estas tareas de gestión es necesario comprenderlas, aunque sea de a poco.
He puesto estos ejercicios a propósito para aprender estas cosas.

Ya, me doy cuenta de ello, las sentencias que no cumplen los condicionales no son compiladas, ¿es eso lo que quieres decir?
 
 Ahora bien, supongamos que pusieras una sentencia tipo "input" asociada a los "if", que esperase que el usuario introdujese un valor para tomar un camino u otro; en ese caso habrá que añadir un bucle que vuelva al "input" constantemente en espera de nuestra entrada, pero a la vez tendrá que dejar de compilar, imagino, para seguir compilando a partir de nuestra orden un trozo de programa u otro, ¿no?

[argentinator]

[

Ya, me doy cuenta de ello, las sentencias que no cumplen los condicionales no son compiladas, ¿es eso lo que quieres decir?

Sí.

Ahora bien, supongamos que pusieras una sentencia tipo "input" asociada a los "if", que esperase que el usuario introdujese un valor para tomar un camino u otro; en ese caso habrá que añadir un bucle que vuelva al "input" constantemente en espera de nuestra entrada, pero a la vez tendrá que dejar de compilar, imagino, para seguir compilando a partir de nuestra orden un trozo de programa u otro, ¿no?

No.

El "input" del lenguaje C es la función scanf().

Ese tipo de cosas no pasan, porque scanf() asigna valores a variables.
Digamos que le has asignado un valor a la variable x.
El identificador x no es una "constante".
Por lo tanto, una expresión como

(x == 1)? hago_tal_cosa() :  hago_tal_otra();

no se evalúa en la fase de compilación, porque el operando (x == 1) contiene a x, que no es una constante.

Lo mismo pasa con el uso de las directivas #if.
No se puede poner expresiones que contengan "algo" variable.

Al escribir algo como :

#if (EXPRESION)
   /* Blah, blah, ... */
#endif

La "EXPRESION" no puede contener a x, ni a nada "variable".

No puede haber interacción con el usuario, porque no se mezclan las etapas de compilación con las del programa ya ejecutable.