Compilar Delphi con codigo en C

[jcrcabre]

No se, ahora no tengo mucho tiempo para contestarte, pero creo que te equivocas cuando crees que se ejecuta el programa pelado en Delphi. Tomemos como ejemplo el caso del control de exepciones, debe haber una "tarea" y con eso no estoy diciendo ni un thread ni otro proceso a parte, sino, supongo que debe ser codigo añadido para que efectue este control.. No se, la verdad que es que con C puedes llegar a las entreñas de tu ordenador, y otras muchas cosas más, entre otras, puedes efectuar cualquier tipo de programación, ya sea concurrente (tan solo compartiendo codigo, cosa que con Delphi NO!!!), programación de TIEMPO REAL, ... Dudo que con Delphi puedas sacarle tanto partido a tu PC como en C, la verdad. Bueno se me acaba el tiempo y deseo que no provoquemos ahora una disjunción de los lenguajes, como se ha comprobado, C y Delphi pueden coexistir para mejorar programas o cualquier otra cosa, da igual. Gracias y que vaya bien.

[santana]

Hola, no puedo reprimirme de participar en mi tema favorito .
Soy una fanática de C, como saben quienes me han leído en hilos anteriores al respecto, pero en honor a la verdad, tengo que reconocer la evidencia.
La potencia que tiene C/C++ frente a la que tiene Delphi, es simplemente de sintaxis, cualquier puntero o forma de tratar datos o acceso a memoria de C/C++ tiene su equivalente en Pascal (por lo tanto Delphi) u otro lenguaje multipropósito, con la excepción de cualquier lenguaje de Scripting o por ejemplo, Java.


En Delphi puedes hacer exactamente todo lo que puedes hacer con cualquier compilador de C/C++, lo único que cambia es que debido a la sintaxis de cada lenguaje el código máquina resultante suele ser más veloz en C/C++ para algun tipo de instrucción. Poco más. Bueno si, una diferencia es que en C++ puedes utilizar la herencia multiple a la hora de extender clases.


Y respecto al acceso total a "las entrañas de la máquina", solo es posible si ese programa realizado en C, Delphi o cualquier lenguaje funciona en el anillo cero del sistema, por lo que no depende del lenguaje que utilices. Solo tienes que decirle al sistema que ese programa es un driver o un servicio de sistema y funcionará en el anillo cero con total acceso a la memoria física y a cualquier dispositivo del pc. Lo que ocurre es que normalmente todos los drivers suelen estar hechos en C++ pero por poder, también se pueden hacer en Delphi.

En Windows NT, 2000 y XP el acceso a la memoria y a las instrucciones privilegiadas de ensamblador lo gestiona directamente sin intermediarios posibles el procesador, porque cuando arranca la primera porción del sistema, este le pide al microprocesador que se coloque en modo protegido (activada paginación y segmentación), y solo se puede cambiar reiniciando. A partir de ahí y dicho a grosso modo, el sistema tiene varias formas de tratar los procesos (como si los etiquetase), unos tienen acceso directo a la RAM, al bus pci, a los puertos de teclado, ratón, COM1, etc. y además pueden usar instrucciones privilegiadas del procesador y otros procesos solo tienen acceso a la memoria que le cede el sistema operativo, estos ultimos procesos tienen que recurrir a las DLLs para poder hacer todas las peripecias que se te puedan ocurrir, las DLLs a su vez hablan con los drivers y así todo está controlado sin posible escapatoria.

W98 también funciona así, aunque no es robusto y puedes bajar cualquier programa al anillo cero e incluso usar las interrupciones de sistema con lo que se desmonta la seguridad proporcionada por el hardware ya que el encargado de decidir en que anillo va cada proceso está implementado con muy baja seguridad, MS dice que es un sistema operativo doméstico y no requiere de tanta seguridad ni robustez.


Estoy soltando uno de mis rollos....... Lo siento .

[__marcsc]

Empezado por santana

Lo que ocurre es que normalmente todos los drivers suelen estar hechos en C++ pero por poder, también se pueden hacer en Delphi.

A mi entender, eso no es gracias al lenguaje en si, sinó a las herramientas disponibles que exisen. No sólo ocurre con drivers, sinó también con juegos y aplicaciones que requieren un rendimiento crítico.

Eso es debido a que existen herramientas como Visual C++, que (por lo visto, yo no lo he tocado demasiado) genera código muy optimizado, y además existen varias bibliotecas de utilidades y clases pensadas con ese propósito. No olvidemos que, aunque Delphi sea un lenguaje multipropósito, la mayoría de las bibliotecas que utilizamos tienen como objetivo la funcionalidad y no la eficiencia. Esto no es así en el caso de Visual C++, donde es mucho más complicado hacer una ventanita que en Delphi, pero probablemente más eficiente. Posiblemente una aplicación de gestión creada con Delphi + VCL sea más lenta que una creada con Visual C++ utilizando la MFC y STL. Pero ahora la siguiente pregunta es: ¿Cuantas horas tardaríamos en Delphi y cuantas en VC++? Seguro que con VC++ unas cuantas más. No por el lenguaje en si, sinó debido a los mecanismos que se han utilizado para generarlas. La gran prueba de esto es: cuántos controladores se desarrollan utilizando C++ Builder? No creo que sean muchos, y también es C++.

En resumen, yo creo que lo importante no es el lenguaje sinó las herramientas y el uso que hacemos de ellas.

Un saludo.

[Julià T.]

Por curiosidad alguien me sabria decir en que lenguaje se programó Dev-c++
http://sourceforge.net/projects/dev-cpp/
Estoy hablando del editor (IDE) no del compilador.

[kinobi]

Empezado por Julià T.

Por curiosidad alguien me sabria decir en que lenguaje se programó Dev-c++
http://sourceforge.net/projects/dev-cpp/
Estoy hablando del editor (IDE) no del compilador.

En realidad es sólo un IDE. Por lo que pone su página web, está hecho con Delphi: http://www.bloodshed.net/devcpp.html

Saludos

[Mick]

Empezado por jcrcabre

No se, ahora no tengo mucho tiempo para contestarte, pero creo que te equivocas cuando crees que se ejecuta el programa pelado en Delphi. Tomemos como ejemplo el caso del control de exepciones, debe haber una "tarea" y con eso no estoy diciendo ni un thread ni otro proceso a parte, sino, supongo que debe ser codigo añadido para que efectue este control..

No entiendo como puedes seguir afirmando lo que afirmas, no das ninguna razon tecnica, hablas de oido pero sin conocimiento del funcionamiento interno de los lenguajes de programación, ni de como trabajan las excepciones.

He puesto el codigo ensamblador que genera tanto el algoritmo en delphi como en C: el ejemplo es icontestable, no hay ningun codigo a mayores en el resultado en ensamblador que pueda enlentecer el codigo de delphi con
respecto al de C.

El mecanismo de excepciones hace comprobaciones, si lo utilizas en tu codigo, es lo mismo que poner un if para comprobar si ha dado error el resultado de una funcion, en C tambien hay un sistema parecido (mirate las funciones setjmp/longjmp) pero un poco mas arcaico. Simplemente en C no se tiende a utilizar esas funciones, y en delphi tampoco es obligatorio que pongas bloques try except.

Empezado por jcrcabre

No se, la verdad que es que con C puedes llegar a las entreñas de tu ordenador, y otras muchas cosas más, entre otras, puedes efectuar cualquier tipo de programación, ya sea concurrente (tan solo compartiendo codigo, cosa que con Delphi NO!!!), programación de TIEMPO REAL, ... Dudo que con Delphi puedas sacarle tanto partido a tu PC como en C, la verdad.

Repito, el codigo ensamblador generado por un lenguaje o por otro es el mismo, de modo que puedes hacer exactamente lo mismo, una vez generado el codigo maquina, no podrias distinguir si el programa fue hecho en delphi o en C, sino mira el ejemplo que he puesto, nadie podria decir a partir del codigo maquina generado si el algoritmo fue programado en C o en delphi.
Independientemente de esto que se pueda hacer programacion en "tiempo real" sea hecha en C o en Delphi no depende tanto del lenguaje sino del sistema operativo, se necesita un sistema operativo de "tiempo real" para realizar programacion de tiempo real verdadera y Windows no lo es.

Empezado por jcrcabre

Bueno se me acaba el tiempo y deseo que no provoquemos ahora una disjunción de los lenguajes, como se ha comprobado, C y Delphi pueden coexistir para mejorar programas o cualquier otra cosa, da igual. Gracias y que vaya bien.

En esto estamos de acuerdo, tanto delphi como C son buenas opciones de programacion, yo utilizo y he utilizado ambos durante mucho tiempo.

Pero hablemos con conocimiento de causa, no te creas todo lo que te dicen u oyes, investiga y piensa por ti mismo no por lo que te digan, no tomes la posicion de emperrarte en afirmar cosas de las que no tienes conocimientos,
aprende ensamblador, funcionamiento de sistemas operativos y compiladores, y cuando tengas estas bases podras entender el ejemplo que he puesto en el otro post y despues podras afirmar con conocimiento de causa y con razones reales lo que pienses acerca de este tema.

Saludos
Miguel

[santana]

Ya se ha hablado alguna vez sobre este tema.

¿Object Pascal para todo?

C++ Builder vs Delphi

Saludos.

[Julià T.]

se puede enlazar directamente a una unidad .obj directamente

Código Delphi [-]
{$EXTERNALSYM MiFuncionEnC}
function MiFuncionEnC(parametros): tipo_resultado;

{$L unidad.obj}

function MiFuncionEnC;external;

[marcoszorrilla]

Dado que ya fuera de lo que era la pregunta de quien iniciara el hilo se ha comenzado un interesante debate el hilo se ha trasladado a este foro de debates.

Un Saludo.