Compilar Delphi con codigo en C

jcrcabre · #1 05-06-2004

Buenas a todos/as!!! Escribo en este foro porque se me ha planteado una duda hace poco por lo representa a si se puede compilar cualquier clase o programa hecho en Delphi, utilizando llamadas a funciones implementadas en C, que se encuantran en una libreria dinamica o estaica.
Mi caso, es que deseo realizar un programa con interficie grafica en Delphi7, no obstante, como éste debe ser eficiente, he implementado unas funciones en C y ahora no se como compilar todo esto junto. Sé que se puede hacer, así que... AYUDADME POR FAVOR!!!!!!!!!!!!!!
Muchas gracias de antemano!!!

--
jcrcabre

cbrrr · #2 05-06-2004

Si tienes todo el código escrito en C puesto en una DLL, no has de tener problemas en hacer llamadas a los procedimientos y funciones exportados de dicha DLL

Si por ejemplo tienes definida la siguiente función en la DLL (lo pongo en Delphi porque no se C)

function MiFuncion(hWnd: THandle); stdcall; export;

Desde Delphi puedes hacer una llamada a dicha función de la siguiete manera

Código:

 procedure Form1.Button1Click(Sender: TObject);
 type
   MiFuncion = function(hWnd: THandle); stdcall;
 var
   Handle: THandle;
 begin
   Handle := LoadLibrary('MiDll.dll');
   if Handle <> nil then
   begin
 	@MiFuncion := GetProcAddress(Handle, 'MiFuncion');
 	try
 	  if @MiFuncion <> nil then
 		MiFuncion(Self.Handle);
 	finally
 	  FreeLibrary(Handle);
 	end;
   end;
 end;

Espero que te pueda servir de orientación

jcrcabre · #3 05-06-2004

Pues creo que me servira, pero ahora otra pregunta, con una libreria estatica (*.lib) sirve?

Gracias.

cbrrr · #4 05-06-2004

Pues no sabría decirte, lo máximo que he hecho entre C y Delphi es precisamente lo que te comento arriba. Un compañero hacía algunas rutinas en C y yo las usaba desde Delphi

jachguate · #5 05-06-2004

Cita:

Empezado por jcrcabre

no obstante, como éste debe ser eficiente, he implementado unas funciones en C

Hola.

Podrias explicarnos porque el código compilado en c será mas eficiente que el compilado en delphi?

Te pido esto, debido a que en estos foros se ha tratado en varias ocasiones el tema de la eficiencia.... y en la mayoría de los casos se plantea prácticamente el mismo nivel de eficiencia. Cual es tu argumento para codificar en c, en este caso en particular, en beneficio de la eficiencia?

Hasta luego.

jcrcabre · #6 05-06-2004

ok, lo probaré. Gracias.

Mick · #7 05-06-2004

No entiendo que para hacer un algoritmo mas eficiente tengas que programarlo en C, delphi no es un lenguaje interpretado como VB o Fox, de modo que como normal general es tan rapido como el codigo en C.
Si algun algoritmo te sale mucho mas rapido hecho en C , normalmente no sera por el lenguaje en si sino porque el codigo fuente hecho en delphi no esta suficientemente optimizado (delphi permite acceder directamente a memoria y trabajar con punteros como en C con lo que se puede hacer exactamente lo mismo y con la misma eficiencia).

En definitiva me da la impresion de que estas complicando el tema utilizando otro lenguaje cuando puedes hacerlo todo en delphi sin perder velocidad.

Saludos

PD: Incluso en caso que se necesite una superoptimizacion
puedes incluir tu propio codigo ensamblador directamente dentro del codigo fuente de delphi.

__marcsc · #8 05-06-2004

En teoría la eficiencia del código máquina que genera el compilador no depende del lenguaje, sinó de la calidad del compilador. Seguramente hay por ahí compiladores de C muy buenos y más optimizados que Delphi pero seguro que también los hay peores. Por otra parte, a menos que necesites hacer muchas "virguerías" dudo que notes mucho la diferencia, ni que te compense "complicarte la vida".

Sólo una opinión

Saludos!

jcrcabre · #9 06-06-2004

Bueno, ahí va mi respuesta. A lo mejor me expresé mal. No creo que un programa sea más eficiente si se ecribe en C, el concepto de eficiencia no esta ligado al lenguaje, sino intrínsicamente al algoritmo en question. A la hora de dissenyar un programa o un proyecto, uno debe plantearse como se va a estrucuturar, y entre varias cosas se debe elegir el lenguaje de programación. Con C un algoritmo es igual de eficiente que en cualquier otro lenguaje, lo que pasa es que en C, entre otras cosas, no hay control de memoria, no hay control de excepciones, ... todo esto favorece que al mismo tiempo que se está ejecutando un programa, se estén ejecutando a la vez diversas tareas ligadas al lenguaje. Por tanto, en C lo que se ejecuta es el programa pelao. Hay muchas más cosas que hacen preferible utilizar C que cualquier otro lenguaje, pero creo que con estas ya os convenceré de que utiliceis C, incluse para programar interficies gráficas. Ahhhh y con C podeis hacerlo TODO!!! y no tiene porque ser más complicado utilizar C que Delphi, al contrario, creo que con C puedes llegar a conceptos informaticos muy sutiles que con otros lenguajes, ni de coña, y de forma muy sencilla.

Bueno espero respuestas.

Mick · #10 06-06-2004

Un programa en delphi se ejecuta "tan pelado" como un programa en C, la lista de razones que das no tienen ningun fundamento técnico, los programas no estan "haciendo otras tareas" están haciendo exactamente lo que tu le digas.

Ejemplo muy simple de implementacion de la funcion strlen en C y en Delphi:

Código:

- Strlen en delphi ------------------------------------------------------------------------------

function strlen_ex(p:PChar):integer;
var
 pp:PChar;
begin
  pp:= p;
  while pp^<>#0 do Inc(pp);
  Result:= pp-p;
end;

-Strlen en C --------------------------------------------------------------------------------

int strlen_ex(char *p)
{
char *pp= p;
 
 while(*pp) pp++;
 return pp-p;
}


-- Delphi, resultado de la compilacion en ensamblador ----------------

strlen_ex:
         mov edx, eax
          jmp .L2
.L1:
          inc edx
.L2:
         cmp byte[edx], 00
          jne .L1
         sub edx, eax
         mov eax, edx
         ret

---- C resultado de la compilacion  (usando GCC  3 optimizacion  O3) -------------

strlen_ex:
	push	ebp
	mov	ebp,esp
	mov	edx,[ebp+8]
	mov	eax,edx
	cmp byte	[edx],0
	je	.L2
.L1:
	inc	eax
        cmp byte  [eax], 00
	jne	.L1
.L2:
	sub	eax, edx
	pop	ebp
	ret

---------------------------------------------------------------------------------------------

Los dos codigos en ensamblador resultantes son muy parecidos.
En el ensamblador generado por delphi no hay ninguna instruccion por el medio que no tenga relacion con el algoritmo que se le ha dicho que ejecute, y que podria hacer pensar que el delphi se dedica a "otras tareas" además de lo que se le ha dicho que haga.

En este caso particular el resultado conseguido por delphi es un poco mas rapido y mas pequeño que el resultado de la compilacion con el GCC 3, debido a que el delphi ha optimizado la funcion de tal modo que no usa la pila para pasar el parametro, usa directamente el registro eax del procesador, en cambio la version del gcc usa la pila.

Pero la diferencia de velocidad es minima.

Puedes probar otros algoritmos y comparar los codigos en ensamblador: Puede que en un determinado algoritmo gane delphi y en otro gane el compilador de C, pero en general las variaciones seran mínimas.

La mayoria de razones que das para considerar que C es mas rapido y se puede hacer mas cosas son "mitos" sin ningun fundamento tecnico. Si se usa mucho C es por cuestiones historicas, y porque es un estandard que esta muy extendido entre todas las plataformas hardware, de modo que cualquier programa en C, tomando las precauciones de compatibilidad adecuadas, se puede recompilar facilmente en muchas plataformas.

Saludos
Miguel

jcrcabre · #11 06-06-2004

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 · #12 07-06-2004

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

.

Mick · #13 07-06-2004

Cita:

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.

Cita:

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.

Cita:

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 · #14 07-06-2004

Ya se ha hablado alguna vez sobre este tema.

¿Object Pascal para todo?

C++ Builder vs Delphi

Saludos.

Julià T. · #15 07-06-2004

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 · #16 07-06-2004

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.

__marcsc · #17 07-06-2004

Cita:

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. · #18 09-06-2004

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 · #19 09-06-2004

Cita:

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