Bonjour!
Voila, je commence la conception d´un projet (nous sommes en fait 4 dans "l´équipe") et nous en sommes en stade de la définition de notre projet : ce sera un jeu vidéo 3D qui utilisera très probablement OPenGL(je voulais utiliser DirectX mais la majorité l´a emporté...).Concernant le langage, il y a encore quelques soucis : je voudrais coder en c++(que j´utilise maintenant depuis 2 ans) et un autre voudrait utiliser CAML.Cette personne travaillera essentiellement sur l´IA (il a été formé sur l´IA).Nous nous posons alors des questions essentielles sur le compatibilité C++/CAML (dans les 2 sens bien sur : incorporation de CAML sous Visual C++ et incorporation de C++ sous objectif CAML) que nous allons pouvoir obtenir.D´abord, existe t´elle et est elle fiable?C´est principalement sur cette question que je voulais soliciter votre aide?
De plus, pour ma tache : la programmation graphique(que je connais bien...en direct3D...mais j´apprendrais OpenGl : les principes doivent etre les mm), est-il préférable de coder des sources et de les incorporer dans le projet CAML ou de coder mon moteur 3D sous la forme d´une dll et de l´utiliser sous objectif CAML?D´abord, une dll windows fonctionne t´elle sous linux?(car nous souhaitons créer un jeu portable).Voila les questions que je me pose.Je vous remercie d´avance.

Désolé d´avoir posté 2 fois le même sujet : j´ai eu un pb sur mon pc.

Bon...
Vaste question que celle de l´interconnexion entre le C++ et l´OCaml.
Fondamentalement, ca s´interface. Mais pas toujours tres bien. C´est pricipalement du au problème de gestion de la mémoire en caml. En effet, la mémoire est garbage collecté. Mais si un segment de mémoire caml est passé en paramètre au C++ et qu´il n´est plus utilisé en caml. Il sera garbage collecté. Ce qui est bien évidement inaceptable.

Globalement on peut appeler du C en caml, mais je ne suis pas sur que l´on puisse appeler du caml en C. En bref, je penses que si ces deux langages doivent s´interfacer, il faut le faire a l´échelle du processus.

Concernant la portabilité des applications. Le code caml devrait être facilement portable. Le code C++ peut etre un peu plus difficilement. Mais globalement, il faudra recompiler ton application. Un binaire (dll ou executable) ne fonctionnera pas directement sous linux (bien qu´on pourrait les charger avec wine).
Finalement, si l´application a été proprement écrit, il ne devrait pas y avoir trop de travail effectuer le portage.

Et l´option "tout faire en C/C++" est elle vraiment a rejeter ?

ou tout faire en Caml ? ...

l´interfacage, même s´il fonctionne (je ne sais pas, par contre, si tu peut compiler le code C avec VC++, ou s´il faut le faire avec gcc. ça doit dépendre de la version de caml que tu utilise) n´est effectivement pas super pratique (et ne peut se réaliser à ma connaissance que depuis du code Caml qui appelerait des fonction en C (donc le "main" est écrit en caml)).

il y a une autre possibilité (mais là,c´est vraiment moche), c´est de faire du F# (type F# dans google), c´est une version .NET de OCaml. Avec ça, tu peut faire facilement l´interfacage avec du C++/CLI ou du C++.NET. Et si tu as de la chance, ça peut tourner avec mono (je sais que c´est assez abouti aujourd´hui). Mais ça va être de la bidouille.

après vérification, on peut tout de même linker du Caml avec du C et appeler le code depuis du C.

Il faut passer l´option -output-obj à ocamlopt (le compilateur code natif de caml) et il produit un fichier objet "C" (je suppose que c´est un truc pour gcc) qui peut être linker avec un programme en C.

Parcontre, je n´ais pas la moindre idée de la manière dont on passe des paramètres dans un sens ou l´autre.

Je penses que tu l´as déjà lu, mais dans le doute:

http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html

Tout d\´abord merci.
Donc, pour résumer ca n\´a pas l\´air très simple et surtout pas très fiable.Comme Fvirtman je pense que le mieux serais d\´écrire l\´ensemble en c++.Mais mon pote qui veut coder en OCaml n\´est pas friand du C++, alors on essaye de trouver des solutions intermédiaire qui feraient plaisir à tout le monde(!, c\´est dur!).J\´étais plus ou moins au courant du problême de la gestion de la mémoire.Je pense que ça va me gonfler de devoir gérer je ne sais combien de pb lié à cette maudite (im)compatibilité, et tout ca pour générer un code qui sera très probablement moche et pas stable.Mais cela dit, je ne compte pas me mettre à Ocaml.Et de toute facon mon apprentissage serait trop long et le projet remis à (bien) plus tard.Donc au final je sais pas...Je vais essayer de continuer à me renseigner sur cette interconnexion.En tout cas merci.
Ha oui Godrik, je l\´avais lu.

Ce sera tout bénef pour ton pote d´apprendre le C++

Bon, je vais etre franc :
J´ai l´impression que tu te laisses marcher dessus alors que c´est toi qui a les meilleurs cartes en main :
Tu connais le C++ avec DirectX : tu as donc de quoi faire un truc en béton.
Mais un de tes potes veut mettre du Caml, et, malgré le fait que tu connaisses DirectX, tes potes te font fléchir pour OpenGL "(je voulais utiliser DirectX mais la majorité l´a emporté...)." , tout en te demandant que ce soit toi qui fasse du OpenGL. "(que je connais bien...en direct3D...mais j´apprendrais OpenGl : les principes doivent etre les mm), "

Si a la rigueur, les autres te disaient "nous on prefere OpenGL, on s´en occupe"... La j´ai l´impression, vu ce que tu écris, qu´ils te disent : "nous on prefere OpenGL, donc TU fais OpenGL"
(cela dit perso, j´aime bien OpenGL, loin de moi le critiquer. D´ailleurs, si tu as besoin de conseils sur OpenGL, je suis la)
Mais ce qui me fait bizarre, c´est que les autres choississent ce que tu dois faire toi.
bref.

Bref, pour conclure, je dirais que ces 2 choix (Caml et OpenGL), vont vous faire faire un projet infiniment moins bien que ce que tu aurais pu faire si tu t´étais imposé (en C++ avec DirectX). C´est dommage.

"Ce sera tout bénef pour ton pote d´apprendre le C++ "
C´est tout bénef aussi d´apprendre OCaml :p

dans un projet tout C++ vous auriez pas tout ces probleme d´interfacage de langage entre Ocaml et C++.

Si c´est toi qui te met au Caml, comment ferez vous la partie 3d (il y a une version Caml de OpenGl?). perso je connais (pas en profondeur) le Caml mais en ce moment j´en bouffe pas mal a la fac et apres 3 ans de programation imperative c´est chaud d´assimiler la philosophie bien particuliere de ce type de langage et d´etre efficace (j´avance mais j´ai un fort sentiment de frustration dut au fait que je peine a faire des action triviales en C et dont la solution m´echappe totalement en Caml)

Il y un une interface OpenGL en Caml qui marche très bien (il y en a plusieurs, mais une seule d´abouti à ma connaissance :
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgl.html ).
L´avantage d´OpenGL sur DirectX est qu´il est portable, et dans le post initial, la portabilité était un critère (sinon, bien sur, ça n´aurait pas d´importance).

L´interfacage C/Caml, s´il n´est pas simple est très fiable (je ne l´est pas vraiment testé, mais tout ce qui sors de l´inria est bon...).

et surtout guyver2 : si aujourd´hui tu ressens un sentiment de frustration à coder en Caml, tu veras dans quelques semaines ou mois, quand tu va gérer ça mieux, l´immense plaisir que c´est d´écrire du code en Caml, tellement la syntaxe de se langage est agréable et souple.

"L´interfacage C/Caml, s´il n´est pas simple est très fiable (je ne l´est pas vraiment testé, mais tout ce qui sors de l´inria est bon...)."
C´est globalement assez compliqué et il y a des interfacage qui ne sont plus que difficile du au probleme de gestion de mémoire. Un ami a essayé d´interfacer simGrid en Caml. Il n´a pas réussit car tu passe des objets au moteur de simgrid, mais tu ne sais pas quand il ne les utilise plus. Du coup, tu ne peux pas garbage collecté intelligement. La seul solution (déplorable) possible étant de garder une reference sur tous les objets passé a simgrid. Ce qui casse completement la garbage collection de caml.

Pour conclure, c´est vraiment magique caml! Pensez fonctionnel n´est pas forcément simple. Mais c´est relativement puissant. Sachant que c´est moins restrictifs qu´haskell ou tu n´as pas la main sur de l´impératif (certes tu peux l´émuler, mais bon... ca devient compliqué)

A noter qu´il existe http://www.swig.org/

Ca ne repond certe a toutes les questions mais cela peut etre une piste.
Je ne l´ai jamais utiliser pour du OCaml mais pour du python c´etait sympa.