AccueilAccueil  FAQFAQ  RechercherRechercher  S'enregistrerS'enregistrer  MembresMembres  Connexion  

Partagez | 
 

 Parser GML

Voir le sujet précédent Voir le sujet suivant Aller en bas 
Aller à la page : Précédent  1, 2, 3  Suivant
AuteurMessage
-Coco-
Utilisateur confirmé: Rang ***


Messages : 545
Localisation : Grenoble - Montpellier
Projet Actuel : Orion VII - 0%

MessageSujet: Re: Parser GML   Mar 6 Nov 2012 - 10:39

En utilisant une bon vieux gros tableau global du genre

std::map<int obj_id, Objet obj>

par exemple dans un namespace (ce que tu as fait dans la onilib, pour la gestion des fichiers) ça marcherait pas ? Puis il suffit de définir certaines constantes en fonction du contexte et c'est éventuellement réglé. (Par exemple un moyen de récupérer le type d'objet)

Bon après je suis pas trop expérimenté mais c'est la première chose qui me vient à l'esprit :p

_________________
Oh, snap.
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Mar 6 Nov 2012 - 18:51

Non le problème n'est pas la gestion des instances, ça j'ai déjà fait avec quelques tableaux (plus rapide que des maps je pense), mais pour la traduction du with GML -> C++.
J'ai bien une idée de comment faire mais c'est un peu miséreux et pas optimisé on va dire ...

_________________
                 
Revenir en haut Aller en bas
-Coco-
Utilisateur confirmé: Rang ***


Messages : 545
Localisation : Grenoble - Montpellier
Projet Actuel : Orion VII - 0%

MessageSujet: Re: Parser GML   Mar 6 Nov 2012 - 22:17

Tu peux toujours passer en revue tout le tableau d'objets, et lorsque un objet a comme "type" l'objet désiré (avec des fonctions get et des constantes) ça agit avec...
Sinon, tu peux faire quelque chose du genre qui crée un tableau par type d'objet lors de la conversion (genre : vector<Obj*> obj_voiture; vector<Obj*> obj_roues; etc) puis un autre tableau qui regroupe toutes les instances, comme ça y'a de quoi faire pour les with, et tout le reste (genre fonctions collision_with, place_meeting etc.), sans pour autant être "trop" ******.

Après si on veut optimiser chais pas...

_________________
Oh, snap.
Revenir en haut Aller en bas
Caly
Utilisateur confirmé: Rang ****


Messages : 1262
Localisation : Haute Normandie
Projet Actuel : Capturer, apprivoiser et dresser des Pokémons sauvages pour faire des spectacles de rue et en faire mon métier.

MessageSujet: Re: Parser GML   Mar 6 Nov 2012 - 22:18

Ils ont fait comment Enigma ?
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Mer 7 Nov 2012 - 8:27

Le code source du compilateur d'Enigma est un vrai bordel et est complètement illisible. C'est même pas la peine de se prendre la tête avec x)
De plus je ne suis pas sur qu'il gère toutes les possibilités syntaxique de GM.
Et aussi, il garde en mémoire les noms de variables, je crois (ça permet de faire des bidouilles mais ça prend de la mémoire).

Coco>
Le gros problème d'un witth en fait, c'est que l'instance vers laquelle il pointe est totalement inconnu au départ.

imagine un
Code:
with(i) {
  a += 1
}

Tu veux faire quoi avec? Razz
Sachant que i peut être l'instance de n'importe quel objet, et i peut aussi être un identifiant d'objet x)

En C++ si je veux faire un i->a++; faut au moins que je connaisse le type de l'objet pour un cast.
Donc je pourrais bien faire un truc qui gère chaque cas d'objet, mais t'imagine un peu la mocheté du truc?

Ça donnerais a peu près:
Code:
if(objType(i) == 0) {
  static_cast<object0>adress[i]->a++;
} else if(objType(i) == 1) {
  static_cast<object1>adress[i]->a++;
}

Y a peut être moyen d'arranger ça avec des templates mais quand même, quel horreur ><
Surtout que tous les objets devront avoir la variable a, du coup, même ceux qui n'en n'ont pas besoin ...



Une autre solution serais de créer pour chaque with une fonction dans l'objet parent a tous les autres.
Elle est plus simple a faire mais on se retrouverais avec je sais pas combien de variables par objet, puis je sais pas combien de fonction with oO
Je pense que ce seras cette solution que j'adopterais si je trouve pas mieux :s

_________________
                 


Dernière édition par onilink_ le Mer 7 Nov 2012 - 14:57, édité 1 fois
Revenir en haut Aller en bas
Morwenn
Très bonne participation


Messages : 151
Projet Actuel : Icare

MessageSujet: Re: Parser GML   Mer 7 Nov 2012 - 11:17

Techniquement, si tu dois identifier un type à l'exécution, les templates n'y changeront rien, et à part les rich pointers qui arriveront peut-être un jour, genre avec le C++1y, c'est très limité niveau récursivité au runtime.

En plus, avec la portée des variables dans un with, tu risques de galérer à mort, savoir si les variables données dans le corps font partie de l'objet désigné par le with ou si ce sont des variables globales ou venant du niveau de boucle précédent Very Happy

Basiquement, j'aurais enregistré chaque type GM dans une collection, et fait une collection de pointeurs pour chaque type dans laquelle tu stockes un pointeur vers chaque objet instancié pour ce type. Ça fait un overhead d'un élément de collection (variable en fonction de la collection) en moyenne pour chaque objet. Après, t'as plus qu'à parcourir les listes pour gérer le with (type), d'autant plus que puisque tes tes objets contiennent leur type, ils ont juste à aller chercher la liste du type correspondant dans la collection globale de types. J'explique ça de manière bordélique, je sais.
Après, je ne sais pas comment sont enregistrés tes objets en mémoire, ou même si tu fais le parser dans le but de faire un compilateur ou un interpréteur. Dans le cas d'un interpréteur, tu ne pourras avoir qu'un type GMObject de toutes façons, comme c'est fait en Python, avec les PyObject. Puisque tu fais un parser, les objets seront forcément gérés comme ça au niveau du parsing de toutes façons, peu importe ce que tu fais de l'arbre une fois ton truc parsé. Donc après, je ne sais pas trop comment tu gères les fonctions, si tu as une liste de fonction associée à chaque type d'objets ou autres... les solutions peuvent varier en fonction de ton implémentation :p

_________________

Dur Dabla, pour qui voudrait écouter un brin de metal celtique.
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Mer 7 Nov 2012 - 14:57

Le parser sert pour l'instant a créer un arbre a partir du GML d'un gm6 pour ensuite faciliter la conversion vers le C++.
Donc pas d’interprétation pour ce projet la.

Sinon pour les types dont tu parle c'est ce que j'ai fait, a peu près.
Pour chaque type d'objet j'ai un array de pointeur qui pointent sur chaque instance.

Par contre j'arrive pas trop a suivre ce que tu dit la x)
T'aurais pas un exemple plus schématisé par exemple?

_________________
                 
Revenir en haut Aller en bas
Morwenn
Très bonne participation


Messages : 151
Projet Actuel : Icare

MessageSujet: Re: Parser GML   Mer 7 Nov 2012 - 19:44

Globalement, une fois parsé, dans ton code C++, tu aurais ça en global :

std::list<obj_heros*> list_heros;
std::list<obj_pancarte*> list_pancarte;
std::list<obj_monstre*> list_monstre;
// etc...

Et pour chaque classe de GM, un constructeur du genre :

Code:

obj_heros::obj_heros(/* ce que tu veux */)
{
    // Initialisation de variables si besoin,
    // de préférence avec liste d'initialisation

    // Ajout de pointeur à la liste globale
    list_heros.push_back(this);
}

Et le destructeur correspondant :

Code:

obj_heros::~obj_heros()
{
    list_heros.remove(this);
}

Comme ça, quand tu dois traduire une construction du type suivant de GM :

Code:

with (obj_heros)
{
    var1 = 5;
    var4 *= 8;
}

Tu peux remplacer par :

Code:

for (obj_heros* xxx: list_heros)
{
    xxx->var1 = 5;
    xxx->var4 *= 8;
}

Ton parseur devra par contre vérifier si tu lui as passé un type ou une instance avant de faire ce genre de trucs pour adapter au besoin le code. Et l'autre emmerde existante, c'est que ça devient de suite plus bordélique avec l'héritage. Ne parlons pas de ceux qui s'amusent à utiliser with all. Dans ce cas, tu devrais avoir soit une liste de tous les objets du jeu, soit une liste des listes d'objets et/ou des trucs qui permettent de s'y retrouver avec l'héritage d'une manière ou d'une autre...

_________________

Dur Dabla, pour qui voudrait écouter un brin de metal celtique.
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Mer 7 Nov 2012 - 20:44

Oui pour un objet de type connus y a pas vraiment de problème, mais pour l'exemple que j'ai montré plus haut, soit un id d'instance, comment tu ferais?
Parce que bon le problème c'est qu'un id passé en paramètre a un with peut toucher tous les types d'objets, et donc si on a une modification de variable (genre a+=1) ben faut que tous les objets l'aient en attribut :/

Comme je l'ai dit plus haut je vois pas comment mieux faire que regarder les variables passées par les with et les mettre en attribut de l'objet Mother dont tous les autres dérivent.
Pas super super :/

_________________
                 
Revenir en haut Aller en bas
Morwenn
Très bonne participation


Messages : 151
Projet Actuel : Icare

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 0:59

Je pense que je "tricherais" en quelque sorte. C'est-à-dire que je me débrouillerai pour qu'il y ait un simple passage textuel d'identifiant passé de GM au C++ sans vérification sur le type. Du genre, dans GM, tu as ça :

Code:

with un_objet
{
    a += 1
}

Je prendrais juste l'identifiant dont le type aurait été de toutes façons déduit au moment où tu l'as utilisé la première fois dans GM, et j'estimerais qu'il a la fonction += et une variable a sans le vérifier. Techniquement, si ça marche sous GM, c'est que quelque part, tu as su que un_objet avait une fonction operator+= et une variable a. Donc arrivé au décryptage du with, je transformerais directement en :

Code:

un_objet->a += 1;

Et ça sans vérifier le type de l'objet ni rien, mais en assumant que l'objet est d'un type quelconque qui possède les variables et fonctions adéquates. Le seul problème de cette méthode, ce serait le cas (à la GM) où le programmeur utiliserait le with pour déclarer les variables internes des objets (ce qui arrive).

Aussi, je n'ai jamais vu personne écrire textuellement with (100012) { /* ... */ } puisque ça n'a généralement aucun sens de le faire sans passer par une variable. Donc ce genre de cas peut être ignoré je pense. Je me contenterais des cas où un type ou un nom de variable sont passés. Pour le type, j'ai montré plus haut, pour le nom de variable, comme je dis, j'assumerais que les variables et fonctions utilisées existent dans la variable sans vraiment faire de vérification. Pas cool, ceci dit.
Après, tu peux peut-être te dé***** en C++11 avec des auto et/ou des decltype, mais je ne vois pas trop comment.

_________________

Dur Dabla, pour qui voudrait écouter un brin de metal celtique.
Revenir en haut Aller en bas
Térence
Utilisateur confirmé: Rang *****


Messages : 2213
Localisation : Oui

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 8:28

Quand tu dit que personne ne fait with(100121), c'est pas tout a fait juste, car moi des fois je fais :
Code:
with(instance_create(10,10,un_objet)
et instance_create te retourne l'id de l'objet créé, donc il risque d'y avoir un problème clinoeuil
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 10:53

Ouai on reviens toujours au même soucis.
Je l'ai dit le with(obj) ne me pose pas de probème, même le with(constante).
Le problème c'est le with(instance).
On ne sais pas de quelle objet l'instance seras a l'avance...


Pour se voir le problème il suffit de se représenter ce code ci:

Code:
if(instance_exists(100000 + mouse_x))
with(100000 + mouse_x) {
  if(a == 2) x += 1 else z -= other.x
  draw_point(x, z)
}

Dans ce cas on est obligé d'avoir les variables a, x, et z comme attribut de tous les objets.
Et de plus il faudra vérifier que les fonctions utilisées dans ce with sont méthodes ou pas des objets...

Donc dans ce cas ça donnerais:
Code:
if(instance_exists(100000 + mouse_x))
{
  if(isInstance(100000 + mouse_x))
  {
  if(ins[100000 + mouse_x]->a == 2)
    ins[100000 + mouse_x]->x++;
  else ins[100000 + mouse_x]->z -= x;
  draw_point(ins[100000 + mouse_x]->x, ins[100000 + mouse_x]->z);
  }
  else for(int i=0; i<objectNumber(100000 + mouse_x); i++)
  {
    if(object_ins[i]->a == 2)
      object_ins[i]->x++;
    else object_ins[i]->z -= x;
    draw_point(object_ins[i]->x, object_ins[i]->z);
  }
}

Pas super joli comme code x)
Et encore je gère ni les parents, ni les mots clés du style all.

_________________
                 
Revenir en haut Aller en bas
Morwenn
Très bonne participation


Messages : 151
Projet Actuel : Icare

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 11:41

C'est vrai que je n'ai jamais utilisé le with instance_create(...). Bon, dans le cas du instance_create, on récupère quand même le type de l'objet puisqu'il est passé à instance_create(), mais ce n'est pas vrai partout. Après, tous les objets de GM sont censés avoir des variables communes (x, y, etc...), donc ça simplifie la vie pour une petite liste de variables dans certains cas, mais ne résout rien dans la plupart des cas...

Tu peux essayer de changer les fonctions qui retournent des id dans toute la bibliothèque standard, en réimplémentant par exemple instace_create() comme ça :

Code:

template<typename T>
T instance_create(int x, int y)
{
    T res = T();
    res.x = x;
    res.y = y;
}

Comme ça, tu ne t’embarrasses pas avec des id partout et tu as à la place l'information du type dans toutes les fonctions qui devaient te retourner des id. Tu peux même utiliser des macros pour donner l'impression que tu passes des types en paramètres à tes fonctions, du genre :

Code:

#define instance_create(x, y, type) \
    instance_create<type>(x, y)

Bref, si tu te dé***** déjà pour faire ça, y'a une moitié de travail de faite au niveau du type. Par contre, ton dernier exemple onilink_, je doute qu'il y ait une solution élégante quelque part.

Il y a d'autres problèmes que tu risques d'avoir avec la généricité de GM, par exemple si quelqu'un fait un truc du genre :
Code:

a = "5"
a = real(a)

Je ne vois absolument pas comment gérer un cas pareil.

_________________

Dur Dabla, pour qui voudrait écouter un brin de metal celtique.
Revenir en haut Aller en bas
Térence
Utilisateur confirmé: Rang *****


Messages : 2213
Localisation : Oui

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 11:49

C'est peut-être HS mais j'ai eu une idée : pour un code GML du style :
Code:
with(obj)
{
a+=1;
}
tu fais en C++ (surement faux au niveau de la syntaxe mais bon...) :
Code:
try
{
obj->a+=1;
}
catch(e)
{
// et là tu fais afficher un message d'erreur
}
Comme ca, s'il manque une variable ou une fonction à l'objet il t'affiche un message, comme ca t'as pas besoin de vérifier s'il a les bonnes variables et méthodes...
Comme dit c'est peut-être HS mais on sais jamais awesome

(et là un truc vraiment HS : c'est quoi la règle 29 Morwenn ?)
Revenir en haut Aller en bas
D-z
Utilisateur confirmé: Rang *****


Messages : 1607
Localisation : Clermont-Ferrand

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 14:50

Morwenn a écrit:
Je ne vois absolument pas comment gérer un cas pareil.

Une union ;)

_________________
 
Home is not a place, it's a feeling.
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 16:32

Utiliser une union dans ce cas, c'est rendre le code généré encore plus moche, et tolérer une mauvaise programmation. De plus on se retrouverais avec des variables encore plus lourdes.
J'interdirais donc ce genre d'opération. De toute façon ce genre de truc est totalement inutile, donc autant respecter des règles de bases même dans GM.
C'est comme certaines fonctions du genre execute_string. Je ne vais pas me prendre la tête a les coder, surtout qu'on perdrait tout l'avantage de compiler le code...

Pour le with obligé de l'implémenter par contre, car il fait parti des mots clés fondamentaux du gml...
Bref je finis mon AST, et quand j'en reviendrait au cas du with si je suis bloqué je créerais peut être un topic d'aide.
Mais bon a mon avis y a pas de solution miracle.

Morwenn>
Dans tous les cas le problème reste le même.
GM vois une instance comme un id, donc with prend en paramètre un nombre.


_________________
                 
Revenir en haut Aller en bas
-Coco-
Utilisateur confirmé: Rang ***


Messages : 545
Localisation : Grenoble - Montpellier
Projet Actuel : Orion VII - 0%

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 17:55

Le problème vient de l'accès à l'objet, ou de l'existence potentiellement nulle des variables ?
Dans le premier cas, il y a tout intérêt à utiliser UN SEUL tableau/map stockant toutes les ID des objets et leurs pointeurs (en plus des différents tableaux), dans l'autre, ben une erreur de compilation permettra de comprendre qu'on fait quelque chose de pas autorisé beh

Sinon pour le stockage des objets pour faire ça optimisé vaut peut être mieux utiliser une map<int, Obj*> avec le int représentant l'ID de l'instance, que l'on pourrait transformer comme ça :

Code:
with (1000+mouse_x)
{
  a+=1;
}

en

Code:
map_obj_all[1000+mouse_x]->a++;

Après il suffirait de détecter si à l'intérieur des paranthèses du with c'est un ID, un type d'objet, ou je ne sais trop quoi (je suis pas expert en with) et remplacer par le bon code en conséquence...

_________________
Oh, snap.
Revenir en haut Aller en bas
Caly
Utilisateur confirmé: Rang ****


Messages : 1262
Localisation : Haute Normandie
Projet Actuel : Capturer, apprivoiser et dresser des Pokémons sauvages pour faire des spectacles de rue et en faire mon métier.

MessageSujet: Re: Parser GML   Jeu 8 Nov 2012 - 18:23

step:
Code:
with( object0 ){
a=5;
b=5;
c=5;
}

==

Code:
execute_string( ev_step, object_name, instance_id, "a=5; b=5; c=5;" );




Sinon niveau organisation :

array_object[objectID]
array_instance[ instanceID, array_object[objectID] ];
Revenir en haut Aller en bas
D-z
Utilisateur confirmé: Rang *****


Messages : 1607
Localisation : Clermont-Ferrand

MessageSujet: Re: Parser GML   Ven 9 Nov 2012 - 16:56

onilink_ a écrit:
Utiliser une union dans ce cas, c'est rendre le code généré encore plus moche, et tolérer une mauvaise programmation. De plus on se retrouverais avec des variables encore plus lourdes.
J'interdirais donc ce genre d'opération. De toute façon ce genre de truc est totalement inutile, donc autant respecter des règles de bases même dans GM.
C'est comme certaines fonctions du genre execute_string. Je ne vais pas me prendre la tête a les coder, surtout qu'on perdrait tout l'avantage de compiler le code...

Ca m'a servi une fois tout de même : une fonction qui retournait un nombre, mais il me fallait pouvoir retourner une valeur "erreur". Là où j'aurais mis un null en Java, j'ai mis une chaîne vide, comme ça je pouvais le tester avec is_real(x). Mais tes arguments sont recevables :p

_________________
 
Home is not a place, it's a feeling.
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Ven 9 Nov 2012 - 18:38

Oui de temps a autres ça peut toujours être utile, surtout pour ce que tu as fait :b

Caly>
J'ai pas compris le rapport x)

-Coco->
Les maps sont intéressantes, mais d'après mes derniers essais c'est plus lent que les tableaux.
Enfin bon je vais faire divers tests et je vous tient au courant :b

Déjà rien que refaire un système d'instance qui fonctionne bien et qui soit rapide et optimisé, c'est pas une mince affaire :b

_________________
                 
Revenir en haut Aller en bas
arthuro
Utilisateur confirmé: Rang ****


Messages : 1297
Localisation : Grenoble / Méribel
Projet Actuel : CBNA

MessageSujet: Re: Parser GML   Sam 10 Nov 2012 - 11:51

Tu fait des id pour chaque instance
tu fait des id pour chaque objet

une liste associative (id d'objet -> list d'instance*) : M1
une liste associative (id d'instance -> instance* ) : M2

tu as plusieurs cas:

Soit dans le with c'est un type d'objet
alors tu parcours la list dans M1 associé à l'id de l'objet

Soit dans le with c'est une id d'instance
tu obtient l'instance en utilisant la map M2.

_________________

D'autres jeux :
In The Cube
In the cube 2
Revenir en haut Aller en bas
D-z
Utilisateur confirmé: Rang *****


Messages : 1607
Localisation : Clermont-Ferrand

MessageSujet: Re: Parser GML   Sam 10 Nov 2012 - 12:12

Le mieux à mon avis c'est pas des listes mais des vectors. Et c'est manifestement comme ça que GM l'implémente.

Edit : cependant tous les types d'objets se retrouvent dans la même liste... Et si tu utilisais un tableau dynamique, indicé par ID, rassemblant des structures contenant le pointeur vers ton objet, et des chaînages vers les objets de même type précédent et suivant dans le tableau ? Tu peux alors récupérer un objet en particulier via le tableau, ou une liste d'objets de même type via les chaînages.

_________________
 
Home is not a place, it's a feeling.
Revenir en haut Aller en bas
-Coco-
Utilisateur confirmé: Rang ***


Messages : 545
Localisation : Grenoble - Montpellier
Projet Actuel : Orion VII - 0%

MessageSujet: Re: Parser GML   Sam 10 Nov 2012 - 18:24

L'accès aux membres des map est certes un peu plus lent que pour des vector, mais pour le coup ça sera plus optimisé et il y aura moins de conditions relou, donc ça sera peut être plus rapide... (En tout cas c'est comme ça que j'aurais fait moi)

_________________
Oh, snap.
Revenir en haut Aller en bas
Morwenn
Très bonne participation


Messages : 151
Projet Actuel : Icare

MessageSujet: Re: Parser GML   Sam 10 Nov 2012 - 21:13

En plus, si tu utilises C++11, tu pourras avoir accès aux unordered_map qui sont plus rapides pour le retrait d'informations, même si un peu plus lentes à l'insertion.

_________________

Dur Dabla, pour qui voudrait écouter un brin de metal celtique.
Revenir en haut Aller en bas
Caly
Utilisateur confirmé: Rang ****


Messages : 1262
Localisation : Haute Normandie
Projet Actuel : Capturer, apprivoiser et dresser des Pokémons sauvages pour faire des spectacles de rue et en faire mon métier.

MessageSujet: Re: Parser GML   Mer 5 Déc 2012 - 21:44

Oni, par pure curiosité et envie d'apprendre comment créer un langage interprété avec un exemple concret pourrais tu partager la source de ton parser stp?
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Mer 5 Déc 2012 - 21:56

Je t’enverrais la source si tu veux mais je doute que ce soit la meilleure façon pour toi d'apprendre.
Tu devrais faire quelques recherches sur la descente récursive: http://en.wikipedia.org/wiki/Recursive_descent_parser

Après t'as le livre "The art of C++" qui a un chapitre complet sur l'écriture d'un interpréteur, et pas mal de documentation sur le net.

Et vaux mieux bien connaitre le fonctionnement d'un ordinateur aussi.

_________________
                 
Revenir en haut Aller en bas
Caly
Utilisateur confirmé: Rang ****


Messages : 1262
Localisation : Haute Normandie
Projet Actuel : Capturer, apprivoiser et dresser des Pokémons sauvages pour faire des spectacles de rue et en faire mon métier.

MessageSujet: Re: Parser GML   Mer 5 Déc 2012 - 22:29

Enfait je veux juste voir à quoi ça ressemble, pas envie de me taper plusieurs pages de lecture car je ne vais pas en programmer un c'est juste histoire de voir à quoi ça ressemble.
Revenir en haut Aller en bas
onilink_
Modérateur


Messages : 8851
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Parser GML   Mer 5 Déc 2012 - 22:38

Bah c'est quasiment pareil que sur la page wikipédia que je t'ai filé x)

_________________
                 
Revenir en haut Aller en bas
Caly
Utilisateur confirmé: Rang ****


Messages : 1262
Localisation : Haute Normandie
Projet Actuel : Capturer, apprivoiser et dresser des Pokémons sauvages pour faire des spectacles de rue et en faire mon métier.

MessageSujet: Re: Parser GML   Jeu 6 Déc 2012 - 8:31

Ok, ok vais lire la page de Wikipedia alors, thanks.
Revenir en haut Aller en bas
Morwenn
Très bonne participation


Messages : 151
Projet Actuel : Icare

MessageSujet: Re: Parser GML   Sam 8 Déc 2012 - 16:34

Sinon, niveau ouvrage de référence, bien que payant, il y a toujours le Dragon Book qui est un ourvrage extrêmement complet concernant le parsing, la compilation, l'interprétation de code, la compilation à la volée, etc...

_________________

Dur Dabla, pour qui voudrait écouter un brin de metal celtique.
Revenir en haut Aller en bas
Contenu sponsorisé




MessageSujet: Re: Parser GML   

Revenir en haut Aller en bas
 
Parser GML
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 2 sur 3Aller à la page : Précédent  1, 2, 3  Suivant
 Sujets similaires
-
» Parser GML

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
Forum Le CBNA :: Informations :: Projets-
Sauter vers: