Avez-vous utilisé l'un des interpréteurs C++ (pas les compilateurs)?

Question

Je suis curieux si quelqu'un a utilisé UnderC, Cint, Cling, Ch, ou tout autre interpréteur C++ et pourrait partager leur expérience.

Answer 1

cint est le processeur de commande pour le package d'analyse physique des particules ROOT. Je l'utilise régulièrement, et ça marche très bien pour moi.

Il est assez complet et sympathise avec le code compilé (vous pouvez charger compilé des modules pour une utilisation dans l'interpréteur ...)

modifier fin :: Copié à partir d'un double plus tard parce que l'affiche sur cette questions ne semblent pas vouloir poster ici: igcc. Je n'ai jamais essayé personnellement, mais la page Web semble prometteuse.

Answer 2

Il y a longtemps, j'ai utilisé un interpréteur C++ appelé CodeCenter. C'était plutôt sympa, même si ça ne pouvait pas gérer des choses comme des champs de bits ou des astuces. Les deux choses intéressantes à ce sujet étaient que vous pouviez regarder quand les variables changeaient, et que vous pouviez évaluer le code C/C++ à la volée pendant le débogage. De nos jours, je pense qu'un débogueur comme GDB est fondamentalement tout aussi bon.

Answer 3

Aussi longtemps que j'utilisé un appel produit instantané C, mais je ne sais pas qu'il ait jamais développé plus

Answer 4

J'ai (il y a un an) joué avec Ch et trouvé qu'il était assez bon.

Answer 5

J'ai regardé en utilisant ch un peu de temps en arrière pour voir si je pourrais l'utiliser pour les DLL de test de boîte noire dont je suis responsable. Malheureusement, je ne pouvais pas vraiment comprendre comment l'obtenir pour charger et exécuter des fonctions à partir de DLL. Là encore, je n'étais pas si motivé et il pourrait bien y avoir un moyen.

Answer 6

Il existe un programme appelé c-repl qui fonctionne en compilant à plusieurs reprises votre code dans des bibliothèques partagées à l'aide de GCC, puis en chargeant les objets résultants. Il semble évoluer rapidement, en considérant que the version dans le référentiel d'Ubuntu est écrit en Ruby (sans compter GCC bien sûr), tandis que le latest git est en Haskell. :)

Answer 7

REMARQUE: ce qui suit est plutôt spécifique à CINT, mais étant donné que c'est probablement l'interpréteur C++ le plus approprié, il peut être valable pour tous.

En tant qu'étudiant diplômé en physique des particules qui a beaucoup utilisé CINT, je devrais vous avertir. Bien qu'il ne « travail », il is in the process of being phased out, et ceux qui passent plus d'un an en physique des particules apprennent généralement à éviter pour plusieurs raisons:

1. En raison de ses racines en tant que C interpretor, il ne interpréter certains des composants les plus critiques de C++. Les modèles, par exemple, ne fonctionnent pas toujours, vous serez donc découragé d'utiliser des choses qui rendent C++ si flexible et utilisable.

2. Il est plus lent (d'au moins un facteur 5) que C++ minimalement optimisé.

3. Les messages de débogage sont beaucoup plus cryptiques que ceux produits par g ++.

4. du scoping est incompatible avec C compilé ++: il est assez fréquent de voir le code de la forme

   if (energy > 30) { 
       float correction = 2.4; 
   } 
   else { 
       float correction = 6.3; 
   } 
   
   somevalue += correction; 
   

   alors que tout compilateur C++ de travail se plaindrait que correcton a disparu hors de portée, CINT permet. Le résultat est que le code CINT n'est pas vraiment C++, juste quelque chose qui lui ressemble.

En bref, CINT n'a aucun des avantages de C++, et tous les inconvénients plus certains.

Le fait que le CINT soit toujours utilisé est probablement un accident historique en raison de son inclusion dans le cadre ROOT. Au moment où il a été écrit (il y a 20 ans), il y avait un réel besoin d'un langage interprété pour le tracé/montage interactif. Maintenant, il y a beaucoup de paquets qui remplissent ce rôle, dont beaucoup ont des centaines de développeurs actifs.

Aucun d'entre eux n'est écrit en C++. Pourquoi? Tout simplement, C++ n'est pas destiné à être interprété. Le typage statique, par exemple, vous permet d'obtenir de grands gains d'optimisation lors de la compilation, mais sert surtout à encombrer et surcontraper votre code si l'ordinateur n'est autorisé à le voir qu'à l'exécution. Si vous avez le luxe de pouvoir utiliser un langage interprété, apprenez Python ou Ruby, le temps qu'il vous faudra pour apprendre sera inférieur à celui que vous perdez en trébuchant sur CINT, même si vous connaissez déjà C++. D'après mon expérience, les chercheurs plus âgés qui travaillent avec ROOT (le paquet que vous devez installer pour exécuter CINT) finissent par compiler les bibliothèques ROOT dans des exécutables C++ normaux pour éviter CINT. Ceux de la jeune génération suivent cette piste ou utilisent Python pour les scripts. Incidemment, ROOT (et donc CINT) prend environ une demi-heure à compiler sur un ordinateur assez moderne, et échouera parfois avec les versions plus récentes de gcc. C'est un paquet qui a servi un but important il y a de nombreuses années, mais maintenant il montre clairement son âge. En regardant dans le code source, vous trouverez des centaines de distributions obsolètes de type c, des trous énormes dans la sécurité de type, et une utilisation intensive des variables globales.

Si vous voulez écrire en C++, écrivez C++ car il est destiné à être écrit. Si vous devez absolument avoir un interpréteur C++, CINT est probablement un bon pari.

Answer 8

Il y a cling projet de Cern de C++ interprète basé sur clang - il est nouvelle approche basée sur 20 ans d'expérience dans ROOT Cint et il est tout à fait stable et recommandé par les gars du Cern.

Voici Google Talk: Introducing cling, a C++ Interpreter Based on clang/LLVM.