[Insoluble] Allocation mémoire pour gen dynamique de code

Citation:

---

Envoyé par zais_ethael

JMais imaginons plutôt que toutes ces fonctions prennent le même argument, par exemple un vecteur d'objets A, A contenant un int pouvant prendre quelques valeurs définies dans une énumération et un void*, et renvoient toutes un objet A.

---

Ca peut être effectivement une solution possible ... que je n'utiliserais pas parce que :

Avantages :
- ça simplifie grandement l'interpreteur
- pas de code ASM à gérer

Mais, Inconvénients :
- tout le code de conversion de type des paramètres va être dupliquer dans toutes les fonctions (passage de vector<A> -> float, float, ...). Donc aucune centralisation, ce qui veux dire, écriture fastidieuse de code un peu partout, d'où risque de bugs lors du "copier-coller-modifier", ...
- de toutes façons c'est pas possible car je n'ai pas la main sur les DLLs à charger (pas de code source), donc impossible de recompiler pour standardiser mes méthodes

Je ne parle absolument pas de recompiler, c'est bien évidemment impossible :)
Il faut savoir utiliser un peu d'astuce. L'interopérabilité avec le C (ou éventuellement C++, mais c'est surtout le C qui est important) est une possibilité dans tous les langages de programmation.
Tous utilisent des wrappers sous une forme ou une autre. Par exemple le Lua utilise un mécanisme très proche de celui que t'ai décrit. Pour appeler une fonction que tu connais, tu crées un wrapper en C qui va récupérer les arguments de type inconnu et en nombre inconnu en provenance du langage de scripting, les décrypter, lancer une erreur si ils ne sont pas bons puis appeler la fonction (que tu connais forcément). Je crois que le python utilise un système à peu près similaire.
Le seul langage à ma connaissance utilisant ce principe est le dotnet. Il permet de définir le prototype d'une fonction en C (nombre d'argument, type, longueur, encodage d'une chaine de caractère,...).
Je te recommanderais plutôt de réfléchir à la première solution, plus réaliste (tu n'es pas Microsoft, tu n'as pas des millions à investir dans un langage :)). Mais rends toi bien compte que ce que tu veux faire est irréalisable tel quel. J'ai l'impression que tu veux laisser la possibilité à tes utilisateurs d'appeler n'importe quelle fonction à n'importe quel moment et n'importe comment, un peu comme on accède à COM en VB. Comment dans ce cas définir le mode de passage d'une chaine de caractères?, le retour par adresse? A moins de créer un langage excessivement proche du C ou du C++ (gestion des pointeurs, taille des types primitifs variable, chaines de caractères "pourries",...) je persiste à dire que ce n'est pas réalisable (et encore).

Citation:

---

Envoyé par zais_ethael

Je ne parle absolument pas de recompiler, c'est bien évidemment impossible :)

---

Ben un peu, si : imposer un framework ou une API que les DLLs doivent respecter, ça implique la recompilation de toutes celles-ci.
Un générateur de wrapper à la SWIG c'est là même chose (mais de l'autre côté).

Citation:

---

L'interopérabilité avec le C (ou éventuellement C++, mais c'est surtout le C qui est important) est une possibilité dans tous les langages de programmation.

---

Justement mon pb. est de rendre mon interpréteur interopérable avec du C.

Citation:

---

Envoyé par zais_ethael

Tous utilisent des wrappers sous une forme ou une autre.

---

Le problème avec le mot wrapper c'est que ça recouvre trop de concepts différents.

Citation:

---

Pour appeler une fonction que tu connais, tu crées un wrapper en C qui va récupérer les arguments de type inconnu et en nombre inconnu en provenance du langage de scripting, les décrypter, lancer une erreur si ils ne sont pas bons puis appeler la fonction (que tu connais forcément). Je crois que le python utilise un système à peu près similaire.

---

Tout le pb. est là : appeller la fonction. On en revient à ma question.

Citation:

---

Le seul langage à ma connaissance utilisant ce principe est le dotnet. Il permet de définir le prototype d'une fonction en C (nombre d'argument, type, longueur, encodage d'une chaine de caractère,...).

---

Tu est déjà allé faire un tour ici :

http://docs.python.org/dev/lib/ctype...continued.html

Et ici ?

http://www.digitalmars.com/d/interfaceToC.html

Citation:

---

Mais rends toi bien compte que ce que tu veux faire est irréalisable tel quel.

---

Bien sur que vouloir prendre en compte toutes les situations possibles, ça tiend de l'utopie ... :sm: ! Mais rassure toi mon usage est trés ciblé. Dans mon cas les bibliothèques dynamiques à charger ne sont pas si en bazarre que ça (au niveau des technologies mises en oeuvre, mais pas du tout au niveau des prototypes). C'est du C en majorité (un peu de C++ pour certaines), pas de redéfinition de types ou de nouvelles structures, les pointeurs et les références ne servent qu'a passer des arguments par adresse, l'allocation se fait toujours dans la DLL, même chose pour la libération mémoire, leur API est trés bien documentée, ...

Ce que je veux juste c'est pouvoir accéder facilement à mes DLLs sans avoir à recompiler mon interpreteur.

Citation:

---

J'ai l'impression que tu veux laisser la possibilité à tes utilisateurs...

---

.

Ne t'inquiètes pas le seul utilisateur ... c'est moi ! J'aurais jamais proposé une solution technique comme ça si c'était professionnel (ça serait aller droit dans le mur :mur:) !

Tu ferais mieux de passer par un langage intermédiaire et un compilateur JIT...

Citation:

---

Envoyé par mchk0123

Ben un peu, si : imposer un framework ou une API que les DLLs doivent respecter, ça implique la recompilation de toutes celles-ci.
Un générateur de wrapper à la SWIG c'est là même chose (mais de l'autre côté).

---

Maiiiiis non. Tu as une dll propriétaire, et bien évidemment les .lib et .h correspondants. Tu crée une biblio C par dessus ça qui ne contient que des fonctions-wrappers (donc d'un prototype fixe) appelant celles de la biblio cible. Tu compiles ton wrapper, tu ne gardes que la dll qui en ressort et voila. Depuis ton espace d'exécution, tu appelles avec les fonctions déja citées la fonction de ton wrapper qui va à son tour appeler celle de la biblio cible. Tu peux même faire un update de la dll propriétaire si ça te chante sans devoir recompiler quoi que ce soit (à condition que le prototype de ses fonctions ne change pas, mais la ça poserait problème dans tous les cas de figure bien évidemment).
Le seul désavantage de cette technique est exactement le même que celui qui apparait en Java. Si ton langage est sensé fonctionner sur plusieurs plateformes avec une sorte de bytecode ou des scripts non-compilés, tu vas devoir compiler le wrapper pour chaque os.

Citation:

---

Envoyé par mchk0123

Tu est déjà allé faire un tour ici :
http://docs.python.org/dev/lib/ctype...continued.html
Et ici ?
http://www.digitalmars.com/d/interfaceToC.html

---

Qu'est-ce que ça prouve? Que python possède en standard un wrapper vers la biblio standard du C? Que le D est un langage d'un fonctionnement similaire au C++ qui permet une compilation combinée avec le C?

Désolé, je ne comprends pas !

C'est quoi un wrapper ?

Regarde ce que me sort wikipedia : http://fr.wikipedia.org/wiki/Wrapper_(informatique)

Ca n'a pas l'air d'être ce que tu dis.

Un wrapper c'est un truc qui enrobe.

La il te sort la définition du design pattern adapter en orienté objet, rien à voir :), ils t'expliquent d'ailleurs qu'un adapter peut être considéré comme un type de wrapper. C'est comme dire que si une table est un meuble tous les meubles sont des tables.
Un wrapper est une couche intermédiaire, généralement destinée à faire la colle entre deux "trucs". Mais quand on parle de faire communiquer deux langages de programmation en général tout le monde comprend, il n'y a pas vraiment de définition.
Tu devrais aller voir comment fonctionne l'intéraction C dans l'un ou l'autre langage de programmation que tu connais (on va naturellement exclure le C++ et le D qui "trichent"). Si tu connais php, python ou encore java ça pourrait être une bonne source d'inspiration.

Bon je déclare définitivement fortait, les DLLs ont l'air d'avoir été compilés avec des options optimisation (en plus peut être différentes) ; ce qui fait que l'ABI n'est pas du tout uniforme.

Pour preuve, en décompilant je m'aperçois que certaines fonctions de la DLL attendent les paramètres via les registres, et d'autres via la pile ... C'est à s'arracher les cheveux.

Merci en tout cas à ceux qui m'ont apporter leurs conseils ; et à ceux aussi, que je n'ai pas crus, quand ils me disaient que je me dirigeais vers une impasse.