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, 10:31 pm
Respuesta #30

feriva

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino


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,274
  • 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,274
  • 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

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
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

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
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,274
  • 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,274
  • 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

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino


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

  • $$\Large \color{red}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 9,171
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
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,274
  • 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).