Même si je suis d'accord sur l'ensemble, je tiens à nuancer un peu ton propos.
il faut compiler pour chaque architecture et chaque compilateur pour lequel le jeux est compatible
Pour l'architecture, c'est vrai ( quoique, sur une multi-arch ia64, on peut exécuter du i386... mais ce serait dommage ). Pour les compilateurs, c'est partiellement vrai.
La difficulté dans un système de plug-in écrit en C++ est de ne pas casser l'API bien sûr, comme pour tout langage, mais aussi l'ABI, ce qui est plus compliqué.
Mais plus compliqué ne signifie pas impossible, une méthode régulièrement utilisée est d'exposer une API C-style, qui est un langage dont l'ABI est stable ( évidemment, il n'y a pas de méthodes virtuelles, déjà, et l'ordre de résolution des paramètres d'une fonction est imposé par le standard, contrairement au C++ ), et d'ensuite refaire une bibliothèque C++ qui l'encapsule si on tiens à retrouver les avantages du C++ ( exceptions, type-safety, notamment ).
Cette méthode permets aussi de pouvoir créer des plug-ins dans d'autres langages, il suffit de créer la lib d'encapsulation correspondante.
Du coup, au final, cette façon de faire permettrait au contraire de faciliter les mods, puisqu'on ne restreindrait plus le langage utilisé au javascript ( qui a, j'ai l'impression autant d'admirateurs que de détracteurs ) mais à tout langage capable d'appeler du C. C'est à dire, la majorité de ceux que je connais.
D'autres jeux, je pense notamment à unvanquished, utilisent des machines virtuelles en C, et la dernière fois que j'ai mis le nez dans ce jeu la, la possibilité d'utiliser LLVM au lieu de QVM était une piste pour permettre un code plus C++ tout en restant exécutable d'une archi à l'autre ( quoique j'ai un doute, on peut vraiment exécuter le même binaire sur un amd64 et sur un proc ARM? À vérifier tiens ).
Pour le problème de sandbox... c'est la même chose en JS non? Je veux dire, l'isolation doit toujours se faire, même si pour le coup, c'est une outil externe qui le fait... et sûrement partiellement j'imagine, je doute qu'il n'y ait aucune protection dans le code lui-même.
En C++ c'est vrai que ça me semble pas évident, il faut à tout le moins surcharger new, delete ( qui sont des opérateurs comme les autres ) pour, je dirai, si je devais faire un truc pareil, interdire tout appel à delete et forcer un retour de std::unique_ptr du new.
Dur, mais à vue de nez, semble faisable et éviter quelques problèmes ( quoique unique_ptr expose potentiellement le pointeur interne via la méthode get. Il faudrait probablement restreindre ce smart pointer pour interdire certains appels, mais ça ne me semble pas infaisable ).
Je précise et j'insiste, que c'est juste une idée en passant, je n'ai pas étudié son bien fondé ni sa faisabilité. En plus, je doute très fortement que 0AD soit écrit en C++11. Et pour cause, il me semble que le dev à commencé bien avant.
[^] # Re: Javascript
Posté par freem . En réponse à la dépêche Dernières évolutions autour de 0 A.D.. Évalué à 2.
Même si je suis d'accord sur l'ensemble, je tiens à nuancer un peu ton propos.
Pour l'architecture, c'est vrai ( quoique, sur une multi-arch ia64, on peut exécuter du i386... mais ce serait dommage ). Pour les compilateurs, c'est partiellement vrai.
La difficulté dans un système de plug-in écrit en C++ est de ne pas casser l'API bien sûr, comme pour tout langage, mais aussi l'ABI, ce qui est plus compliqué.
Mais plus compliqué ne signifie pas impossible, une méthode régulièrement utilisée est d'exposer une API C-style, qui est un langage dont l'ABI est stable ( évidemment, il n'y a pas de méthodes virtuelles, déjà, et l'ordre de résolution des paramètres d'une fonction est imposé par le standard, contrairement au C++ ), et d'ensuite refaire une bibliothèque C++ qui l'encapsule si on tiens à retrouver les avantages du C++ ( exceptions, type-safety, notamment ).
Cette méthode permets aussi de pouvoir créer des plug-ins dans d'autres langages, il suffit de créer la lib d'encapsulation correspondante.
Du coup, au final, cette façon de faire permettrait au contraire de faciliter les mods, puisqu'on ne restreindrait plus le langage utilisé au javascript ( qui a, j'ai l'impression autant d'admirateurs que de détracteurs ) mais à tout langage capable d'appeler du C. C'est à dire, la majorité de ceux que je connais.
D'autres jeux, je pense notamment à unvanquished, utilisent des machines virtuelles en C, et la dernière fois que j'ai mis le nez dans ce jeu la, la possibilité d'utiliser LLVM au lieu de QVM était une piste pour permettre un code plus C++ tout en restant exécutable d'une archi à l'autre ( quoique j'ai un doute, on peut vraiment exécuter le même binaire sur un amd64 et sur un proc ARM? À vérifier tiens ).
Pour le problème de sandbox... c'est la même chose en JS non? Je veux dire, l'isolation doit toujours se faire, même si pour le coup, c'est une outil externe qui le fait... et sûrement partiellement j'imagine, je doute qu'il n'y ait aucune protection dans le code lui-même.
En C++ c'est vrai que ça me semble pas évident, il faut à tout le moins surcharger new, delete ( qui sont des opérateurs comme les autres ) pour, je dirai, si je devais faire un truc pareil, interdire tout appel à delete et forcer un retour de std::unique_ptr du new.
Dur, mais à vue de nez, semble faisable et éviter quelques problèmes ( quoique unique_ptr expose potentiellement le pointeur interne via la méthode get. Il faudrait probablement restreindre ce smart pointer pour interdire certains appels, mais ça ne me semble pas infaisable ).
Je précise et j'insiste, que c'est juste une idée en passant, je n'ai pas étudié son bien fondé ni sa faisabilité. En plus, je doute très fortement que 0AD soit écrit en C++11. Et pour cause, il me semble que le dev à commencé bien avant.