Qui dit que l'interpreteur va se comporter de la meme facon que le compilateur ?
Si en prime l'interpreteur n'embarque pas toutes les 'fonctionalites' (templates par exemple) que le compilateur, l'interet devient de plus en plus faible.
En gros, tester avec un interpreteur :
- pour du haut niveau (fonctionnalite, algo, prototypage) -> OK
- pour du bas niveau (implementation, repetabilite, robustesse du code, performances....) : NON.
Quand le soft est proprement ecrit, il ya un moyen plus propre de faire du test unitaire.
Tu compiles et ensuite tu interfaces avec un langage interprete (bash, python, perl, tcl... c'est selon) : on appelle ca une moulinette.
En prime, on fait tourner selon des scenarii definis dans les specifications, ca tourne pendant la nuit, et on genere des beaux rapports de test automatiques (texte, html, xml) qu'on peut tranquillement regarder avec mozilla.
C'est quand meme plus civilise que faire mouliner un interpreteur, non ?
Pour faire de l'educatif :
- ben compiler du C/C++ deja (et comme dit plus haut, le temps de compile est souvent negligeable pour les didactiques)
Pour les projets didacticiels plus gros ca permet de s'interesser (et d'apprendre a gerer) aux problemes annexes : makefiles, cvs. (Et mine de rien, c'est un truc qui bouffe du temps, alors tant qu'a faire autant l'apprendre tot)
- sinon les langages interpretes purs (Ruby, python) sont beaucoup plus elegants, lisibles etc etc.
Et pour faire de l'algorithmique/prototypage, c'est nettement plus interessant.
Sinon, ben un projet de plus et c'est tant mieux, peut etre que d'autres y trouveront plus d'interet (j'espere). En tous cas aller voir le projet peut donner des idees (de ce que l'on veut faire, OU ne pas faire)
[^] # Re: UnderC : un interpréteur c++
Posté par matiphas . En réponse à la dépêche UnderC : un interpréteur c++. Évalué à 6.
Qui dit que l'interpreteur va se comporter de la meme facon que le compilateur ?
Si en prime l'interpreteur n'embarque pas toutes les 'fonctionalites' (templates par exemple) que le compilateur, l'interet devient de plus en plus faible.
En gros, tester avec un interpreteur :
- pour du haut niveau (fonctionnalite, algo, prototypage) -> OK
- pour du bas niveau (implementation, repetabilite, robustesse du code, performances....) : NON.
Quand le soft est proprement ecrit, il ya un moyen plus propre de faire du test unitaire.
Tu compiles et ensuite tu interfaces avec un langage interprete (bash, python, perl, tcl... c'est selon) : on appelle ca une moulinette.
En prime, on fait tourner selon des scenarii definis dans les specifications, ca tourne pendant la nuit, et on genere des beaux rapports de test automatiques (texte, html, xml) qu'on peut tranquillement regarder avec mozilla.
C'est quand meme plus civilise que faire mouliner un interpreteur, non ?
Pour faire de l'educatif :
- ben compiler du C/C++ deja (et comme dit plus haut, le temps de compile est souvent negligeable pour les didactiques)
Pour les projets didacticiels plus gros ca permet de s'interesser (et d'apprendre a gerer) aux problemes annexes : makefiles, cvs. (Et mine de rien, c'est un truc qui bouffe du temps, alors tant qu'a faire autant l'apprendre tot)
- sinon les langages interpretes purs (Ruby, python) sont beaucoup plus elegants, lisibles etc etc.
Et pour faire de l'algorithmique/prototypage, c'est nettement plus interessant.
Sinon, ben un projet de plus et c'est tant mieux, peut etre que d'autres y trouveront plus d'interet (j'espere). En tous cas aller voir le projet peut donner des idees (de ce que l'on veut faire, OU ne pas faire)