Idem, j'y ai vraiment cru pendant une journée. Ce n'est que le jour suivant que j'ai commencé à m'en douter mais comme  newbiecontest est filtré au travail j'ai du attendre le soir pour en avoir le coeur net!
J'ai déprimé toute une soirée à la pensé de la disparition du meilleur site de challenge en-ligne du web.
Non, vraiment il ne faut plus refaire ce coup là. Pour la prochaine fois je préfere une des idées de Folcan ^^
En tout cas, longue vie à newbiecontest!

  var_tab[foo]->type = 0;

Ici tu utilise la valeur non initialisé qui est dans la case var_tab[foo] du tableau pour définir à quelle adresse tu va écrire. Ensuite tu écris 0 à de cette adresse là ... Bref, tu écris à un endroit plus ou moins random de la mémoire, donc ca plante plus ou moins en random.
Il te faudrait surement un boucle qui fait les mallocs pour tous les objets t_var que tu veux stoquer.
Attentions aux pointeurs sur pointeurs... c'est facile de se planter.

Pour ton deuxième problème je ne peux pas faire grand chose car il manque la moitié du code.

all: $(OBJ)
        $(CC) $(CFLAGS) -o $(NAME) $(SRC) $(HEADERS)

Ton makefile marche surement mais il est quand meme buggé (les .o sont complilé et après on ne s'en sert plus).
Ca serait plutot ceci:

all: $(OBJ) $(HEADERS)
        $(CC) $(CFLAGS) -o $(NAME) $(OBJ)

A mon avis tu n'as pas compris ce qu'est une pile.
Cherche un peu sur le web.

Je te conseille d'utiliser une pile en faisant du 'shift reduce'.

Tu implemente d'abbord un "scanner" qui te renvoie les tokens un par un dans l'ordre (1 token = 1nombre ou 1 operateur ou 1 parenthese)

Ensuite, pour le "parser" tu emplile les tokens un par un (=shift) en regardant à chaque fois si tu peut faire un 'reduce'  à partir des X elements du haut de la pile.
par exemple tu aura comme règles de 'reduce'
N '+' M  =>   +
                /  \
               N   M
Ici, les 3 elements du haut de la pile sont remplacés par 1 seul arbre contenant l'operation +.

Pour les parentheses la règle de 'reduce' serait:
'(' N ')'   =>   N

Pour gérér la précédence des operateurs (entre l'addition et la multiplication), il faut aussi aller regarder le token qui n'est pas encore sur la pile avant de faire le 'reduce'.

E.g. Si la pile contient:

4, '+', 5 et que le token suivant est '*' il ne faut pas encore faire le 'reduce' mais plutot faire un autre shift (car * > +).

A la fin de l'algo tu va te retrouver avec un seul element dans la pile qui contiendra un arbre que tu pourra parcourrir pour trouver la réponse (comme ceux dans les message précédants).


Voila, j'espère que ca pourra t'aider. Ce n'est pas très détaillé et il peut meme y avoir des détails erronnés, mais ca devrait te donner une idée de comment un vrai parseur fonctionne.
Je ne pense pas que la notation polonaise inversée va t'aider beaucoup car cela demande de changer l'input du programme...
Mais c'est vrai que ce sont les expressions les plus simples à parser.

Je suis un acien d'Epita et j'avais résolu ce problème comme ca.

 

Oui, les deux sont faux et ce n'est pas en rapport avec l'élément 0 ou 1.

Il faut passer le paramètre par adresse et non par valeur (sinon fscanf ne pourra rien modifier).
Dans ton example tu envoye le contenu (non initialisé) de RAM[0] à fscanf au lieu de l'adresse à laquelle il pourra sauver le résultat (RAM ou &RAM c'est pareil). il faut un int* au lieu d'un int.
Donc pour la première case du tableau ( RAM[0] ) :

Code:

fscanf(test, "%d", RAM)

ou pour la deuxieme  ( RAM[1] )

Code:

fscanf(test, "%d", RAM + 1)

Bonjour,

Ca dépends un peut de ce que tu veux apprendre.
Pour la programmation simple je te conseille un tuto sur le python ou le php (fait une recherche sur le net). Le c/c++ c'est bien pour le cracking et la proximité avec le code machine (c.f. K&R) . Et pour etre un vrai guru de la prog lis SICP: http://mitpress.mit.edu/sicp/

C'est dur celui-là. Ca me fait que des "Calmos" ou des erreurs SQL.
Quelqu'un aurait un incide?