(http://www.stratos-ad.com/forums/style_images/1/pip.gif)
Vector con OCAML (http://www.stratos-ad.com/forums/style_images/1/pip.gif)
Aprovechando que he estado mirandome el lenguaje ocaml he creado un modulo de vectores 3d para este lenguaje.
Para los que desconozcan este lenguaje decir que la lluvia es Sevilla es una pura maravilla , es una mezcla entre lenguaje funcional (c, c++, etc...) y lenguaje imperativo (lisp, fortran, etc...), con recolector de basura y mil y una cosas, en fin una verdadera maravilla. Para los que duden de la velocidad de ejecucion de este tipo de lenguajes saber que va casi tan rapido que el c y mas rapido que el c++ en la mayoria de casos (estoy seguro que la mayoria de gente piensa que el c++ es igual de rapido que el c, usar clases tiene mucha sobrecarga de codigo).
Mi opinion es que el c se ha quedado pequeño para aplicaciones de cierto nivel y que el c++ es un verdadero bodrio hecho a base de parches sobre el c (exagerar es mi forma de vida). Cosas que no me gustan del c/c++:
- Templates
- El casi nulo soporte de RTTI en los compiladores
- Los punteros (de aqui provienen la mayoria de bugs, por no hablar de los stack overflow)
- La gestion de memoria
- Los destructores de clases (se deberian llamar destructores de la humanidad )
- Tener que ir declarandolo todos dos veces e incluso tener que declarar de que tipos son las variables cuando del contexto se puede sacar claramente de que tipo es
- y un sinfin mas de cosas.
La unica ventaja que le veo al c/c++ respecto al ocaml es la gran cantidad de gente que hay haciendo cosas para ese lenguaje (eso es algo que debemos cambiar nosotros).
Pagina oficial -
http://www.ocaml.org/OCAML SDL -
http://ocamlsdl.sourceforge.net/Algunos cutre-juegos hechos en ocaml -
http://ropas.kaist.ac.kr/caml/humps/caml_Games.htmlGoogle: c++ sucks -
http://www.google.com/search?q=c%2B%2B+suc...a+en+Google&lr=Por cierto, no penseis que estoy haciendo apologia nazi en contra del c++ solo quiero que la gente se de cuenta de que la vida no acaba en ese lenguaje. Teneis que daros cuenta de que un programa hecho en ocaml requiere menos tiempo de produccion que si se hubiera hecho en c++.
Si quereis ya os ire dando mas la bara con el rollo este que os he metido sobre el ocaml
Código:
(* Vector tolerance for vector comparision *)let tolerance
= 0.001(* Vector class *)class vector3 x_init y_init z_init
=object(self
) (* Vector props *) val mutable x
= x_init
val mutable y
= y_init
val mutable z
= z_init
(* Get vector properties *) method get_x
= x
method get_y
= y
method get_z
= z
(* Set vector properties *) method set_x xs
= x
<- xs
method set_y ys
= y
<- ys
method set_z zs
= z
<- zs
method set xs ys zs
= x
<- xs
; y
<- ys
; z
<- zs
method move xoffset yoffset zoffset
= x
<- x +. xoffset
; y
<- y +. yoffset
; z
<- z +. zoffset
(* Calc length of the vector *) method magnitude
() = sqrt x
*.x +. y
*.y +. z
*.z
(* Normalize the vector *) method normalize
() = let length
= 1. /. self#magnitude
() in x
<- x
*. length
; y
<- y
*. length
; z
<- z
*. length
end(* Create a 3d vector *)let create
?(x = 0.
) ?(y = 0.
) ?(z = 0.
) () = new vector3 x y z
(* Sum of vector *)let (+
) v1 v2
= create
~x:
(v1#x +. v2#x
) ~y:
(v1#y +. v2#y
) ~z:
(v1#z +. v2#z
)(* Sub of vectors *)let (-
) v1 v2
= create
~x:
(v1#x -. v2#x
) ~y:
(v1#y -. v2#y
) ~z:
(v1#z -. v2#z
)(* Vector product *)let ( * ) v1 number
= create
~x:
(v1#x
*. number
) ~y:
(v1#y
*. number
) ~z:
(v1#z
*. number
)let ( * ) v1 v2
= create
~x:
(v1#x
*. v2#x
) ~y:
(v1#y
*. v2#y
) ~z:
(v1#z
*. v2#z
)(* Vector div *)let (/
) v1 number
= create
~x:
(v1#x /. number
) ~y:
(v1#y /. number
) ~z:
(v1#z /. number
)let (/
) v1 v2
= create
~x:
(v1#x /. v2#x
) ~y:
(v1#y /. v2#y
) ~z:
(v1#z /. v2#z
)(* Vector eq *)let (=) v1 v2
= if tolerance
= 0.
then v1#x
= v2#x
&& v1#y
= v2#y
&& v1#z
= v2#z
else abs_float
(v1#x -. v2#x
) <= tolerance
&& abs_float
(v1#y -. v2#y
) <= tolerance
&& abs_float
(v1#z -. v2#z
) <= tolerance
(* Vector neq *)let (<>) v1 v2
= not (v1
= v2
)(* Return the dot between two vectors *)let dot v1 v2
= v1#x
*. v2#x +.
v1#y
*. v2#y +.
v1#z
*. v2#z
(* Return the cross vector of two vectors *)let cross v1 v2
= create
~x:
(v1#y
*. v2#z -. v1#z
*. v2#y
) ~y:
(v1#z
*. v2#x -. v1#x
*. v2#z
) ~z:
(v1#x
*. v2#y -. v1#y
*. v2#x
)(* Return the minimum vector of two vectors *)let minimum v1 v2
= create
~x:
(if v1#x
< v2#x
then v1#x
else v2#x
) ~y:
(if v1#y
< v2#y
then v1#y
else v2#y
) ~z:
(if v1#z
< v2#z
then v1#z
else v2#z
)(* Return the maximum vector of two vectors *)let maximum v1 v2
= create
~x:
(if v1#x
> v2#x
then v1#x
else v2#x
) ~y:
(if v1#y
> v2#y
then v1#y
else v2#y
) ~z:
(if v1#z
> v2#z
then v1#z
else v2#z
)Daos cuenta de que en ningun sitio he declarado el tipo de las variables, pero el compilador automaticamente se da cuenta de que son floats.
Estadisticas:
- ocaml 129 lineas
- este mismo objeto en c++:
53 lineas la cabecera
204 lineas el fuente
total 257 lineas justo el doble menos uno
Si quieres enviar tu propio código hazlo a eth_cotd@lycos.es . También puedes hacerlo a través de un mensaje privado por el foro si el código es corto.
[/list]
¿Es un lenguaje interpretado?, es que no veo ejecutables, solo fuentes en los ejemplos que me he bajado.
Aquí hay un compilador, aunque aun no lo he probado.
The Objective Caml distributionY un quickly-atajo a las FAQ,
FAQ JOUME PEICH
Citarlenguaje funcional (c, c++, etc...) y lenguaje imperativo (lisp, fortran, etc...),
Eso lo tienes muy mezclado, c,c++ y fortran son imperativos y lisp funcional....
NO estoy de acuerdo en la mayoría de cosas que has dicho de C++, el verdadero problema de C++ es que el standard no exige a nivel de código compilado.
Ves mal las templates? O_O. Explícame eso de que las clases añaden mucha sobrecarga y al mismo tiempo mejor no usar templates... cómo harías tú containers? (Listas, Tablas, Árboles....). O templates o herencia de containers o cosas raras en programaciónb funcional, no conozco más formas... y las más rápida es sin duda con templates.
Destructores? <_< , qué tiene de malo automatizar el liberar recursos para disminuir errores//leaks porque al programador se le olvida?
Para mí las líneas de código no son un indicador muy significativo de nada, busca algún estudio sobre el tema, un programador invierte un 20%-30% sólo en la implementación
PD: Gracias por el COTD, no conocía ese lenguaje
Pues yo diría que a menos líneas de código, menos probabilidades de cometer un error.
Sobre los destructores, el problema puede ser precisamente olvidarte de ellos XD por eso me parece mejor que el lenguaje tenga un manager propio "más listo".
En fin, no le doy mucho a la programación, pero por lo que he oído de profesores y alumnos que sí que le dan, C/C++ no sería el lenguaje más usado hoy en día si no fuera porque es el lenguaje más usado hoy en día (qué paradoja, ¿no?). Vamos, que "es lo que hay", frente a otros lenguajes mejores (más apropiados para determinados ámbitos, mejor dicho)pero menos usados, o incluso híbridos entre otros lenguajes y C/C++ para aprovechar las ventajas de ambos mundos.
Por ejemplo, uno de los profesores habló de una integración de Python y C en las conferencias de Software Libre en la UJI:
http://www.aditel.org/jornadas/03/ponencias/py_cP.D.: No entiendo nada del código :rolleyes:
Sobre el COTW: Muy interesante(pero de verdad, no como la revista), siempre está bien salirse de C++ aunque sólo sea por experimentar. Cualquier lenguaje que no utilice una sintaxis como la de Scheme me parece fenomenal :-)
Y sobre la batalla dels lenguatges:
Algo parecido a lo que dice Mars: C++ es el lenguaje más usado porque se puede hacer todo desde él. La mayoria de las librerias importantes están orientadas(no digo exclusivamente) a C/C++.
"Si algo no puede hacerse con C++, es que no puede hacerse" - leí una vez por ahi ;-)
Yo por mi parte quiero ver como evolucionan las plataformas .NET/Mono, porque C# me parece una evolución(que no sustitución) lógica. Java tampoco está mal, pero para juegos por ahora no es lo más adecuado(ya sé que hay muchas iniciativas de juegos en Java >:-))
Lo bueno de .NET/Mono es que el paso de bytecode a código nativo se realiza sólo en la primera ejecución. En cambio Java la traducción se realiza siempre(a no ser que esto haya cambiado ¿?)
Alguien más se atreve a vaticinar el futuro de los lenguajes? :ph34r:
EDIT:
Pensad con las siguentes premisas(personales) en las diferencias entre un Hello World en C++ y otro en ASM(se ve bastante claro con ese ejemplo):
Menos lineas de código: más productividad.
Más lineas de código: más control sobre lo que se hace(no más calidad).
Más lineas, más propensión a errores(pero más sintácticos que de concepto, creo yo).
CitarJava tampoco está mal, pero para juegos por ahora no es lo más adecuado
sólo hay que ponerse, héchale un vistazo a este juego:
Alien Flux © Puppy Games
Mira la máquina que pide(los requerimientos recomendados para jugar en condiciones):
Citar
recommended requirements:
Windows 95 OSR2, Windows 98, Windows ME, Windows2K, Windows XP
500MHz processor
48MB of free RAM
20MB of hard disk space
3D card with hardware accelerated transform & lighting (T&L) (GeForce, Radeon, etc)
OpenGL 1.4 graphics drivers
CitarLo bueno de .NET/Mono es que el paso de bytecode a código nativo se realiza sólo en la primera ejecución. En cambio Java la traducción se realiza siempre(a no ser que esto haya cambiado ¿?)
Creo que el JIT de java lo que hace es traducirlo la primera vez y luego se ejecuta directamente en el código nativo. De todas formas seguro que hay alguien más entendido en java que nos saca de dudas...
En cuanto a este lenguaje OCAML, he de decir que me gusta la sintaxis. Quizás me gusta porque lo veo muy familiar, es 'practicamente' C++
sin llaves, el número de líneas entre los dos lenguajes es muy similar si exceptuamos las chorrocientas llaves
{ } que tendriamos que añadir al código en C++.
En cuanto a mi experiencia personal, yo me paso todo el dia programando, y un 5% del tiempo escribiendo código.
un saludo
Aquí hay algo sobre el JIT:
JIT CompilerLo que no me queda claro es cómo es de inteligente el JIT, o la duración de su caché(a la hora de re-compilar código ya ejecutado). El .Net guarda los ejecutables nativos bajo WINNT/Assembly.
Para no decir sólo cosas malas de Java :-) :
Para juegos en móviles lo que se lleva ahora es Java. El C++ ni siquiera se considera.
Desde luego las razones que has dado para odiar c++ son algunas que le hacen ser un lenguaje potentisimo.
Personalmente si quereis probar un lenguaje que os saque de apuros ( no hablo de hacer el codigo en menos lineas de código q es algo que importa poco), sea rapido, orientado a objetos o funcional, con muchas librerias, embebible facilmente y relativamente facil de aprended usad python. Yo lo he usado en mi proyecto de fin de carrera y me he quedado prendado de la rapidez con la q se trabaja (muy util a la hora de hacer herramientas que no importa la velocidad de ejecucion, normalmente). Incluso ahora lo uso en el trabajo dada la gran cantidad de código util que hay por ahi.
Sobre OCAML? vim soporta su sintaxis coloreada. Y eso es todo lo que tengo q decir acerca de eso (forrest gump)
saludos
Cita de: "ZaelSiuS"Para no decir sólo cosas malas de Java :-) :
Para juegos en móviles lo que se lleva ahora es Java. El C++ ni siquiera se considera.
He usado dos tipos de telefonos (siemens y nokia) con java y la velocidad da realmente mucha pena y no son malos procesadores, son capaces de reproducir mp3 por ejemplo. Sin embargo todo lo q pone java a disposicion del programador se sale.
saludos
Esta es la tercera vez que intento escribir este mensaje (estoy en el trabajo con un windows huelga decir mas :-P). Los dos primeros intentos intente escribir una respuesta larga pero como veo que no puedo hare respuesta corta.
Primero miraros una comparacion de velocidades entre diferentes lenguajes
http://www.bagley.org/~doug/shootout/, visita imprescindible.
Algunos comentarios de usuarios que lo han usado (parece uno de esos anuncios del abdomineiser 2000 a la semana tenia los abdominales de rocky :P)
http://caml.inria.fr/users_comments-eng.html.
Una introduccion
http://caml.inria.fr/FAQ/stephan.html para usuarios que vienen el c/c++.
Unos mini-ejemplos escritos en ocaml para que se os habra el apetito
http://caml.inria.fr/FAQ/exemples-eng.html.
Y dos aplicaciones escritas en ocaml un web browser
http://pauillac.inria.fr/mmm/eng.htm y un cliente para el edonkey (seguro que muchos lo conoceis)
http://www.nongnu.org/mldonkey/.
Lo que le falta al ocaml es que haya una comunidad mas grande detras, pero este tipo de cosas son las que debemos cambiar nostros. Yo por ahora me he propuesto hacer algun mini-engine-3d para linux (como si tuviera tiempo libre (nooo) ) si quiereis cuando tenga algo visible ya os lo mostrare.
Y por ultimo una autentica joya
http://www.stokely.com/lighter.side/stroustrup.html una entrevista con el creador del lenguaje c++ y no, no es broma, la entrevista es ciertamente autentica.
Respecto a lo de líneas de código, hay que saber distinguir lo que son cantidad de caracteres escritos de cantidad de instrucciones. No creo que C sea menos propenso a errores que Pascal por ser menos claro sintácticamente, más bien todo lo contrario.
SamSaga, sigo sin entender las quejas sobre templates y destructores, sobre todo sobre templates.
Los resultados son curiosos pero este me ha llamado especialmente la atencion:
http://www.bagley.org/~doug/shootout/bench...ch/reversefile/ en el cual gana nada mas y nada menos q bash! XDD no se supone q bash esta programado en c? como es posible que incluso llamando al interprete tarde menos q el mismo programa en c? ¿?
saludos
Cita de: "samsaga2"y no, no es broma, la entrevista es ciertamente autentica.
Dudo que sea cierta :-), pero aun así es interesante. Al comienzo de la página se puede leer esto:
CitarWebmistress' note: This is fiction.
si no pusiera eso aun me lo creería XD
Cita de: "ethernet"Los resultados son curiosos pero este me ha llamado especialmente la atencion:
http://www.bagley.org/~doug/shootout/bench...ch/reversefile/ en el cual gana nada mas y nada menos q bash! XDD no se supone q bash esta programado en c? como es posible que incluso llamando al interprete tarde menos q el mismo programa en c? ¿?
saludos
Si haces click en el nombre del lenguaje podras ver el codigo fuente:
#!/bin/bash
# $Id: reversefile.bash,v 1.2 2001/09/19 00:53:46 doug Exp $
# http://www.bagley.org/~doug/shootout/
# from David N. Welton
tacEsto quiere decir que habria que mirar en que esta programado el tal tac.
Cita de: "CoLSoN2"si no pusiera eso aun me lo creería XD
Otia, menudo chasco, me han engañado XD eso pasa por creerme lo que dice la gente, mil perdones (nooo)
Cita de: "samsaga2"Cita de: "ethernet"Los resultados son curiosos pero este me ha llamado especialmente la atencion:
http://www.bagley.org/~doug/shootout/bench...ch/reversefile/ en el cual gana nada mas y nada menos q bash! XDD no se supone q bash esta programado en c? como es posible que incluso llamando al interprete tarde menos q el mismo programa en c? ¿?
saludos
Si haces click en el nombre del lenguaje podras ver el codigo fuente:
#!/bin/bash
# $Id: reversefile.bash,v 1.2 2001/09/19 00:53:46 doug Exp $
# http://www.bagley.org/~doug/shootout/
# from David N. Welton
tac
Esto quiere decir que habria que mirar en que esta programado el tal tac.
JUAZ; bestial, si tac esta programado en c es para cerrar esa pagina y no volver a entrar XDDD
Bueno, si no recuerdo mal de Sistemas Operativos, el intérprete bash es más rápido en cuestión de navegación por el sistema de ficheros que C/C++, aunque esté implementado en ellos. Supongo que se entiende más rápidamente con el sistema operativo o algo.
No me hagáis mucho caso, toy amodorreixon.
mars: eso es como deciir q con asm no se podrian hacer en ciertos casos programas tan rapidos como en c, lo cual es mentira, todos sabemos que en el peor caso deberian funcionar igual.
saludos
Yo me refiero a que el nivel de privilegios que tiene bash sobre el sistema a nivel de ejecución es superior al que tendría un código compilado de un usuario.
En fin, sólo puedo decirte por experiencia que un script que hiciera un grep de un determinado texto costaba menos en bash que en C (en tiempo de ejecución y por supuesto en tiempo de programación). Yo tampoco lo acabo de entender, pero mira, estaba de ejercicio en una práctica y los resultados eran esos.
Un saludo.
Bueno, como igual mi memoria me engaña y acabo de encontrar el libro de Sistemas Operativos, voy a hacer una pequeña prueba sobre anubis comparando la ejecución del siguiente código:
ps -ef |grep 'parametro' | sort -k 1,2
Cuyo equivalente en C sería:
#include<stdio.h>
#include<fcntl.h>
#include<string.h>
#include<unistd.h>
main(argc, argv)
int argc;
char *argv[];
{
int fd, fds0[2],fds1[2],fds2[2];
char car;
if (argc!=3)
printf ("Uso incorrecto\n");
else
{
pipe(fds0);
if (fork()!=0)
{
close(0);
dup(fds0[0]);
close(fds0[0]);
close(fds0[1]);
fd=creat(argv[2],0755);
while (read(0, &car, sizeof(char))>0)
{write(1,&car,sizeof(char));
write(fd,&car,sizeof(char));
}
close(fd);
} else {
pipe(fds1);
if (fork()!=0)
{
close(0);
dup(fds1[0]);
close(fds0[0]);
close(1);
dup(fds0[1]);
close(fds0[1]);
close(fds1[1]);
execlp("sort","sort","+1","-2", NULL);
exit(-1);
} else {
pipe(fds2);
close(fds0[1]);
close(fds0[0]);
if(fork()!=0)
{
close(1);
dup(fds1[1]);
close(fds1[1]);
close(fds2[1]);
close(0);
dup(fds2[0]);
close(fds2[0]);
close(fds1[0]);
execlp("grep", "grep", argv[1],NULL);
exit(-1);
}
else
{
close(fds1[0]);
close(fds2[0]);
close(1);
dup(fds2[1]);
close(fds2[1]);
close(fds1[1]);
execlp("ps","ps","-ef",NULL);
}
}
}
}
exit(0);
}
Está sacado del libro de ejercicios de la cosa esta, voy a intentar compilar aunque seguro que he metido mucho la gamba por ahí (¿quién decía que no era importante el número de líneas o nosequé?).
Ahora os digo, si lo consigo.
0->time ps -ef |grep 'parametro' |sort -k 1,2
real 0m0.134s
user 0m0.030s
sys 0m0.100s
0->time programa parametro fichero2
real 0m0.112s
user 0m0.000s
sys 0m0.010s
Efestiviwonder, le cuesta menos con C :rolleyes:
Citar(¿quién decía que no era importante el número de líneas o nosequé)
YO, pero lo entendiste mal. Ya maticé que hablo de número de líneas, no de número de instrucciones. Cantidad de texto escrito por instrucción, si lo prefieres. La diferencia entre llamar a una variable i o llamarla ContadorDeAlgoQueOcupaUnWeboDeEscribir :D. O entre una { de C y un BEGIN de PASCAL.
Mars: no des vueltas a algo obvio
Lo evidente es evidente hasta que deja de serlo. Prefiero cuestionarlo todo y asegurarme. :blink:
También cabe decir que las pruebas de tiempo sobre el servidor Anubis tienen la peculiaridad de que varían dependiendo de los procesos de otros usuarios que se estén ejecutando. En una de las pruebas, la versión bash me sacaba .115 y la versión en C .141. Supongo que necesitaría un programa o comando más complicado y costoso para apreciar bien la diferencia. Lo que le he pasado, a un ordenador con doce procesadores y más ram que disco duro tengo yo, no le cuesta ni un peo.
De paso copio el párrafo del libro que me hacía dudar:
"Las llamadas al sistema son el interfaz mediante el cual el usuario puede acceder a los diferentes servicios que proporciona el Sistema Operativo. Se encuentran en el nivel más bajo de interacción con el sistema. Tanto los comandos que hemos visto en prácticas anteriores como el propio shell son programas que utilizan este interfaz para llevar a cabo las funciones deseadas".
Pues eso, que lo que yo entendí de eso es que el intérprete de comandos tiene prioridad sobre otros programas de usuario.
CitarLo que le he pasado, a un ordenador con doce procesadores y más ram que disco duro tengo yo, no le cuesta ni un peo.
(genial) . Algún dato más sobre ese MONSTRUO?
claro xDD si al caballo rapido le pones un tio de 200 kg encima corre menos q el mas lento a priori.
Si ejecutas los dos procesos exactamente en las mismas condiciones, maxima prioridad etc gana CLARAMENTE Y SIN DUDARLO el programa en c, ya solo porque bash tiene q abrir el fichero .sh leerlo y parsearlo.
Eso siempre y cuando el programa que llama bash y el q usas en c sean el mismo. Si tienes un .c lentisimo y al q llama bash es rapidisimo pues no hay discusion alguna.
Y por otra parte que es lo mas bajo para ti? para mi lo mas bajo es hacer llamar system call, que es el nivel mas bajo que puedes tener (me refiero por encima del kernel)
Creo que estais mezclando la velocidad con el tocino. Lo primero que hay que mirar a la hora de programar algo es el algoritmo (mucho antes que el lenguaje) seguramente el tac este programado en c pero va mas rapido porque usa algun algoritmo mas rapido y optimizado que el del programa de muestra que hayan hecho en c.
Cita de: "Grugnorr"CitarLo que le he pasado, a un ordenador con doce procesadores y más ram que disco duro tengo yo, no le cuesta ni un peo.
(genial) . Algún dato más sobre ese MONSTRUO?
http://www.si.uji.es/servidors/anubis.thtmlSobre el tema:
Ethernet, no es necesario que sigamos con el tema, está muy claro que yo de programación no tengo ni idea y seguro que tienes razón porque además parece obvio. Sólo he apuntado todo eso como volcado de memoria de lo que he dado, pero como dice samsaga2 debo haber mezclado conceptos y estoy muy mareado y me voy a dormir. Bona nit.
¡Pero si es muy temprano aún, Mars! ;)
Comentandolo en el irc y mirando el código del programa en c es claramente optimizable usando mmap. Simplemente da una idea de lo veracidad de los test puestos en esa web.
saludos
Sigo dandole caña al ocaml, creo que ya estoy en nivel medio de conocimiento del lenguaje (a por el nivel avanzado ahora :P). Estoy montando un engine 3d con este lenguaje a base de la libreria sdl para ocaml y la libreria ocamlgl, y ya tengo alguna cosa visible. Podreis observar que es el fichero de ejemplo del test de engines (es el castillo2), se muestra como un simple objeto estatico a base de un display list. Solo comentar que es un gustazo poder cargar objetos y cosas en memoria sin tener que preocuparse de punteros ni de acabar liberandolo (pero como opengl no esta pensado para ocaml los display lists y textures hay que liberarlos a mano). El engine esta ahora mismo unicamente para linux (no tengo ganas de matarme a compilar las librerias para windows). Todo funciona con una media de unos 120/190 fps (la captura se ve menos porque capturar para la ejecucion del programa unas milesimas) bajo un K7 con una GeForce 4 MMX (yo quiero pixels shaders :( ). Una fotillo:
(http://kkag.sourceforge.net/screenshot.jpg)
¡Hey, mola!
Citar(pero como opengl no esta pensado para ocaml los display lists y textures hay que liberarlos a mano)
Uhmm, no decías que odiabas los destructores que evitarían que se te olvidara liberar un recurso? <_<
Cita de: "Grugnorr"Citar(pero como opengl no esta pensado para ocaml los display lists y textures hay que liberarlos a mano)
Uhmm, no decías que odiabas los destructores que evitarían que se te olvidara liberar un recurso? <_<
Es correcto pero el problema con la libreria opengl para ocaml es que el api es exctamente igual y como consecuencia por cada glNewList toca un glDeleteList B). Pero esto no es nada nuevo otros lenguajes como al python le ocurre exactamente igual.
¿¿¿¿¿¿¿¿¿¿¿¿??????????? Eso sucede en c++,c y en todoso los lenguajes q conozco, opengl se define asi XD. Creo q no he entendido el sentido de la discusion.
y por cierto en python hay destructores
hola, he encontrado este hilo, y bueno, os cuento mi problema... He ido a estudiar a francia, y tengo una asignatura, Inteligencia Artificial, en la que la prácticas son con CAML... aquí la gente lleva dando este lenguaje desde hace 3 años, y para mí es nuevo... me gustaría saber dónde puedo encontrar ejercicios resueltos, porque por lo menos para pasar el primer semestre, me piden ejercicios que no se ni por dónde cogerlos, y me podría apoyar en algunos ya hechos...
Creo que has establecido un nuevo récord al ejecutar un jutsu prohibido sobre un post de hace 5 años.
Cita de: "ZaelSiuS"Creo que has establecido un nuevo récord al ejecutar un jutsu prohibido sobre un post de hace 5 años.
jutsu?? qué es eso?? jeje...
es que no hay forma de encontrar una base de conocimiento de caml por ningun lado...
qué mítico y el samsaga empeñado en utilizar lenguajes rarísimos. A ver si lo ve y nos dice qué tal la fue :).
Pues vengo un poco tarde en responder. OCaml mola mucho pero ya ni me acuerdo de donde tengo el código del motor ese XD.
Agosto 2003 . Conjuro . Enero 2008 . Conjuro . Noviembre 2009.
8o :.. ^_^
Juas, pero y lo que mola recordar viejos tiempos qué, ¿eh? Yo no le doy mucho a esto de la programación... quién me lo iba a decir...
Es curioso ver cómo han evolucionado las cosas (o no) desde lo que escribíamos en la primera página.