Autor Tema: Proyecto de Curso (Comentarios): Programación en C (2013, por Argentinator)

0 Usuarios y 1 Visitante están viendo este tema.

04 Enero, 2013, 06:37 pm
Respuesta #20

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.

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.

 





04 Enero, 2013, 06:49 pm
Respuesta #21

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.
Ahhh, si es que no le has puesto paréntesis, por eso no le entendía :D

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í.

04 Enero, 2013, 06:57 pm
Respuesta #22

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
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.



04 Enero, 2013, 06:58 pm
Respuesta #23

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)

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".


04 Enero, 2013, 07:20 pm
Respuesta #24

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.

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.   

04 Enero, 2013, 07:23 pm
Respuesta #25

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
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.



04 Enero, 2013, 07:29 pm
Respuesta #26

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.
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.

04 Enero, 2013, 07:46 pm
Respuesta #27

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)

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.


04 Enero, 2013, 10:04 pm
Respuesta #28

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.


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?

04 Enero, 2013, 10:17 pm
Respuesta #29

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
[

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



Sí.

Citar
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.

04 Enero, 2013, 10:31 pm
Respuesta #30

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.


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


Ah, luego lo que hace el compilador, sospecho, es traducir todo el lenguaje de alto nivel que hemos escrito a código máquina, y con eso es con lo que se trabaja cuando uno está manejando el programa; o sea, que corre enteramente en código máquina.
La verdad es que, aunque haya dicho eso, me extrañaba que su pudiera salir de un lenguaje de bajo nivel así cómo así para después volver como si nada, pero como se ha avanzado tanto en esto de la informática... pues no sabía.   

Una pregunta, ¿existe el comando stop() aquí?

05 Enero, 2013, 12:15 am
Respuesta #31

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
No sé si entiendo que estás diciendo.

No se vuelve del código máquina...

Lo que ocurre es un proceso de traducción sucesiva en varias etapas.

He intentado explicar este proceso acá:

Etapas del preprocesador

El compilador hace varias traducciones que transforman el código fuente en C a otro código fuente TAMBIÉN en C, no a código de máquina.
Hace varias veces eso.

Después que termina de hacer esas traducciones, es que recién se dispone a traducir finalmente al código de máquina definitivo.
Esto último se hace una sola vez, y no hay modo de volver (de forma sana) al código original.

05 Enero, 2013, 12:23 am
Respuesta #32

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
MMmmm... No sé.

Creo que estoy complicando demasiado el asunto con tan sólo el "Hola Mundo" y sus amigos.

 >:D

El preprocesador es un tema complicado, y tan sólo estoy poniendo ejemplos básicos.

Creo que lo voy a terminar ahí, aunque haya muchas más opciones interesantes para explorar.

Además, debo intentar hacer algún programa que haga algo interesante.
Pero también me gusta aprovechar para discutir las vicisitudes (¿delirios?) del lenguaje C, que son muchas, y se complican enseguida.


05 Enero, 2013, 12:45 am
Respuesta #33

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.
MMmmm... No sé.

Creo que estoy complicando demasiado el asunto con tan sólo el "Hola Mundo" y sus amigos.

 >:D



No te preocupes, no lo complicas, es complicado, :D que es distinto.

 Según he consultado en Internet por ahí, parece ser que durante la compilación sí se pasa a código en números binarios y después  se ensambla inmediatamente; ahora bien, no he podido enterarme si eso de "ensamblar" ser refiere al código código ensamblador de antes, del que yo sí conocía un poco básicamente, o es otra cosa.
 De todas formas, tú ve a tu aire, que yo te sigo como pueda y ya con la práctica me iré enterando. Además, parece que tiene cosas bastante parecidas al Javascript en cuanto a declaración de variables locales y algunas cosas así que conozco también de forma básica (de hacer tonterías con el Flash Macromedia).

Saludos y gracias.

05 Enero, 2013, 06:59 am
Respuesta #34

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.
Una curiosidad que yo no sabía, fíjate lo que dice aquí:

(es un fragmento de lo que viene en este enlace) http://es.wikipedia.org/wiki/Lenguaje_ensamblador

"Los programas hechos por un programador experto en lenguaje ensamblador son generalmente mucho más rápidos y consumen menos recursos del sistema (memoria RAM y ROM) que el programa equivalente compilado desde un lenguaje de alto nivel. Al programar cuidadosamente en lenguaje ensamblador se pueden crear programas que se ejecutan más rápidamente y ocupan menos espacio que con lenguajes de alto nivel."

Es decir, que los compiladores son menos perfectos que los seres humanos a la hora de ahorrar espacio y hacer que un programa funcione más deprisa  :o

05 Enero, 2013, 09:42 am
Respuesta #35

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
MMmmm... No sé.

Creo que estoy complicando demasiado el asunto con tan sólo el "Hola Mundo" y sus amigos.

 >:D



No te preocupes, no lo complicas, es complicado, :D que es distinto.

 Según he consultado en Internet por ahí, parece ser que durante la compilación sí se pasa a código en números binarios y después  se ensambla inmediatamente; ahora bien, no he podido enterarme si eso de "ensamblar" ser refiere al código código ensamblador de antes, del que yo sí conocía un poco básicamente, o es otra cosa.
 De todas formas, tú ve a tu aire, que yo te sigo como pueda y ya con la práctica me iré enterando. Además, parece que tiene cosas bastante parecidas al Javascript en cuanto a declaración de variables locales y algunas cosas así que conozco también de forma básica (de hacer tonterías con el Flash Macromedia).

Saludos y gracias.


Lo que pasa es que me estás mezclando cosas.

Estábamos hablando del preprocesador.
El preprocesador nunca transforma a lenguaje de máquina, sino que solamente transforma un programa en C, con algunas directivas (o sea cláusulas con #), en otro programa escrito también en C, pero sin directivas #.

Es que las directivas del preprocesador son sólo declaraciones de tipo "abreviatura".
El preprocesador "desenrolla" esas abreviaturas y las muestra explícitamente.
En la entrada que escribí de mis notas: Etapas del preprocesador
hay un ejemplo de cómo trabaja el preprocesador, yendo en varias etapas de traducción que van quitando las cláusulas #.

_________________

Luego, el ciclo de compilación es algo complejo que contiene varias etapas, que yo he simplificado para que se entienda.

Yo dije esto:

Programa-que-uno-escribe-en-C ---------> Preprocesador-traduce-a-programa-en-C-equivalente-pero-sin-directivas ---------> Compilador-traduce-esto-a-código-de-máquina-del-programa-ejecutable.

Bien, obviamente me he saltado algo en el medio en el último paso.
Es lo que vos mencionás sobre el ensamble.

El "ensamble" no tiene nada que ver con el lenguaje "ensamblador".

Lo que hace el compilador es traducir los diferentes archivos involucrados en un programa (que en general son muchos en un proyecto serio), que todavía no son el ejecutable definitivo.
Esos archivos "compilados" contienen las librerías ".h" y otros archivos que andan por ahí, junto con los enlaces y relaciones que el programados ha elegido entre todos los archivos del proyecto.

El "ensamble" consiste en tomar nota de todas esas relaciones, y "enlazar" todos esos archivos (que es un trabajo hecho por un programa llamado "enlazador" o "linker"), que es lo que finalmente "fabrica" definitivamente el programa ejecutable ".exe".

El compilador, en teoría, no se encarga de hacer el enlazado, sino el programa "enlazador".
El "ensamble" es esta unión o enlazamiento de archivos para formar uno definitivo ejecutable.

Cuando en el IDE wxDevC++ seleccionamos la opción "Compilar", resulta que hace todo junto: el preproceso, luego la "compilación" propiamente dicha, y finalmente el enlazado (o ensamble)..

Un compilador bien hecho tiene que permitir que el programador tenga control sobre esas etapas, porque en proyectos grandes conviene compilar algunos trozos o archivos una sola vez, y así modificar sólo unos pocos archivos cada vez, que serían los únicos que hay que compilar "de verdad", mientras que la única tarea que habría que hacer siempre sería la del enlazado, que es más sencilla y consume menos recursos.


05 Enero, 2013, 09:59 am
Respuesta #36

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Una curiosidad que yo no sabía, fíjate lo que dice aquí:

(es un fragmento de lo que viene en este enlace) http://es.wikipedia.org/wiki/Lenguaje_ensamblador

"Los programas hechos por un programador experto en lenguaje ensamblador son generalmente mucho más rápidos y consumen menos recursos del sistema (memoria RAM y ROM) que el programa equivalente compilado desde un lenguaje de alto nivel. Al programar cuidadosamente en lenguaje ensamblador se pueden crear programas que se ejecutan más rápidamente y ocupan menos espacio que con lenguajes de alto nivel."

Es decir, que los compiladores son menos perfectos que los seres humanos a la hora de ahorrar espacio y hacer que un programa funcione más deprisa  :o

Bueno, el compilador lo hizo también un ser humano.

El "lenguaje ensamblador" o "assembly" es una cosa, y el "programa ensamblador" o "assembler" es otra, salvo que ambas se traducen con la misma palabra "ensamblador" al castellano.

El assembler hace tareas de "ensamble" similares a las que expliqué para los compiladores en C.
Fijate en la sección Assembly del artículo en inglés de Wikipedia, que me parece más preciso:

Assembly language

A program written in assembly language consists of a series of (mnemonic) processor instructions and meta-statements (known variously as directives, pseudo-instructions and pseudo-ops), comments and data. Assembly language instructions usually consist of an opcode mnemonic followed by a list of data, arguments or parameters.[4] These are translated by an assembler into machine language instructions that can be loaded into memory and executed.



El hecho de que un programador experto en lenguaje ensamblador pueda hacer programas más eficientes que uno hecho en C y luego compilado a código máquina, no es algo sorprendente, ya que un compilador está hecho para realizar traducciones en un estilo sistemático, que además "se defienda" de toda una serie de posibles diferencias y problemas en las máquinas o sistemas donde tiene que correr.

El compilador procura crear un código máquina "seguro", que funcione en todos los sistemas, y eso sólo se puede hacer si se agregan muchas instrucciones de máquina extra, dando un código máquina más engorroso.

Además, el compilador no es capaz de detectar redundancias.

Otro problema son las funciones de las bibliotecas, que el programador tiene que aceptar como vienen, y no puede cambiarlas. Ellas pueden estar deficientemente programadas, sin que el programador tenga opción de poder mejorarlas.

Habrá otras razones por las cuales un código "compilado" es menos eficiente, pero no tengo ganas de pensar en eso...

Una razón para esa falta de eficiencia es que el programador de alto nivel ignora los recursos de la máquina que están involucrados en algunas tareas.
Por ejemplo, es de esperar que las funciones de entrada/salida consuman muchos recursos, así que hay que ingeniárselas para disminuir los accesos a disco o a pantalla.

Además, los lenguajes de alto nivel realizan tareas de gestión, a fin de simplificarle la vida al programador, y que no tenga que renegar siempre con los mismos problemas del lenguaje máquina.
Estas gestiones automáticas seguramente que exageran las precauciones, y hacen programas más ineficientes.

Pero no veo cuál sea el problema.

Si uno realmente está preocupado por lo que hace la máquina, los recursos y los tiempos, bien puede aprender a programar en ensamblador, y listo.

Aquí estamos estudiando el lenguaje C, que es cercano a la máquina, pero sigue siendo de alto nivel.

Compilar en C da programas más eficientes y rápidos que con otros lenguajes.

Aunque igual algo podemos llegar a hacer...  ::)

05 Enero, 2013, 05:04 pm
Respuesta #37

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.


Compilar en C da programas más eficientes y rápidos que con otros lenguajes.

Aunque igual algo podemos llegar a hacer...  ::)

 El C está muy bien :) no hace falta aprender el engorro ése que requiere aprenderse un montón de números o tener siempre una lista al lado.

(voy a ver lo que has puesto nuevo)

05 Enero, 2013, 07:22 pm
Respuesta #38

feriva

  • Matemático
  • Mensajes: 9,056
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
  • No soy matemático, eso es una etiqueta.
Ayer estuve haciendo fabricando algunas rutinas y, en unas de ellas, de operaciones de números con "int" y con scanf, etc., no me devolvía el control y  la ventana del cdm se cerraba casi antes de abrirse.
 Depuré y el depurador me regañó por poner el getchar() cuando estaba trabajando sólo con int. Pero el caso es que vi un vídeo en el que, en un IDE Turbo no sé cuántos, sí funcionaba, y sin orden ninguna aparente que devolviera el control. Lo demás estaba todo bien, tenía su librería, su "main" y todo, sólo que no le metí ninguna cosa de texto asociada al char, eran números int.

 ¿Qué se hace en ese caso, qué comando hay? Yo he visto que en tu programa del macro, en el que defines una función para las variables (A,B), al usar el comando de identificadores #define no ocurre eso y sí devuelve el control, pero si se declaran variables en plan normal, digamos, entonces no, al menos en esta IDE.

 Otra cosa, después de utilizar el debug, no sé que pasó que cada vez que abro el Windows, y la IDE después, me aparecen un montón de ventanas flotantes con especificaciones, estado de registros y demás; las cierro ya ya está, puedo trabajar, pero es un rollo y no sé dónde ha que dar para que no salgan más.

Saludos.

05 Enero, 2013, 08:51 pm
Respuesta #39

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,272
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Bueno, no sé qué decirte porque no entiendo qué es lo que hiciste en tu programa.

En cuando al debug, no lo he probado, así que no sé qué efectos produce el debugger del IDE que estamos usando.

Si uno empieza a hacer muchas cosas de golpe, sin orden, se pierde el control de las cosas.

Hay que introducir cambios de a poco, ya sea en los programas como en nuestra rutina de trabajo con el IDE, para irse familiarizando. Si no, no se entiende nada.

Tendrías que colgar acá tu programa, si querés que entienda el problema.

Creería que con los programas que yo hice hasta ahora, todo tiene que funcionar sin problemas, ya que me he ajustado al estándar, lo cual quiere decir que tiene que funcionar en cualquier sistema, bajo cualquier circunstancia.

(En realidad nuestro compilador GCC no se ajusta del todo al estándar C99, pero en lo hecho hasta ahora no hay problemas).