Pour le moment, je considère que vous envisagez de réécrire ou non un interpréteur de langues de programmation que je maintiens en C ++. L'interprète est actuellement implémenté dans c.
Mais je me demandais, est la mise en œuvre primaire , car, certainement, les gens ont certainement des versions de nombreux interprètes utilisant une langue autre que celle utilisée par les auteurs originaux - de tout populaire Interprète linguistique de programmation Actuellement utilisé aujourd'hui écrit en C ++?
Et, sinon, est une bonne raison de ne pas écrire un interprète en C ++? Je crois comprendre que le code C ++, si écrit correctement, peut être très portable et peut potentiellement compiler pour fonctionner aussi vite que compilé C code qui fait la même chose.
10 Réponses :
Les langages de programmation les plus populaires ont commencé à être créés avant de disposer de nombreux bons compilateurs C ++ disponibles. Par conséquent, les principaux interprètes de ces langues n'ont pas commencé à C ++ et une fois que vous avez mis beaucoup de travail à un interprète de travail, vous ne le jetez généralement pas simplement parce qu'il pourrait maintenant être écrit en C ++.
Et si vous démarrez un nouveau projet pour un interprète écrit en C ++, il doit aller un long chemin à devenir la primaire mise en œuvre.
L'utilisation de LLVM pourrait aider (et c'est C ++).
@Klaim: Ouais, par exemple, Clang est un compilateur sérieux pour C / C ++ / Objective-C, basé sur LLVM et écrit en C ++, mais on peut difficilement affirmer que c'est le compilateur primaire pour ces langues ...
On peut difficilement affirmer que tout compilateur pour ces langues est "primaire".
Et j'étais plus en pensant aux nouvelles langues comme D. En fait, il est recommandé de commencer par LLVM pour tout nouveau compilateur de langue.
Une différence fondamentale entre les compilateurs et les interprètes, cependant, est la nécessité de la rapidité et de l'efficacité de ce dernier. Certainement, personne ne veut être assis autour de la journée à attendre un programme de compilation, mais si le résultat est bien optimisé et qui fonctionne rapidement une fois que cela a été compilé, les gens ne vont pas vraiment se plaindre. Mais un interprète doit exécuter un programme à partir de zéro chaque fois est exécuté, la vitesse est donc une véritable préoccupation; L'étape "Compilation" (si le programme est compilé en bytecode, une arborescence de syntaxe abstraite, ou autre) effets vraiment la vitesse globale du temps d'exécution.
La Fondation GNU a récemment annoncé que toutes les nouvelles versions de GCC seront écrites en C ++.
@spongl AllanMCrae.com/2010/06/GCC-IN-CXX L'adoption / la conversion sera lente et non faite dans «C ++ pour le C ++ Sake», mais cela se produira éventuellement.
Je crois << A HREF = "http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html" rel = "NOFOOL NOREFERRER"> gcc.gnu.org/ml/gcc/2010-05 /msg00705.html > est le fil qui a annoncé qu'ils ont décidé de Autoriser C ++ dans le code de la GCC, qui fait pas signifie que cela va être réécrit . Ce serait fou, imo.
C'est trop tard maintenant pour GCC. Face à Clang, je suppose qu'ils abandonneront lentement GCC.
@LITB: Son va être de nouveau terminé, bien que cette fois, GCC soit probablement à la retraite permanente, j'espère juste que certains des pettes ego-pettent de GCC ne font pas partie des rangs de clangs.
@LitB "Ils" qui? Les gars à la FSF? @Hippicoder Si les "pettes ego-pattes" de GCC sont de bons programmeurs, pourquoi ne devraient-ils pas aller aux rangs de collage? (Ils devraient respecter la conception, les lignes directrices et quoi que ce soit de la cliquet de toute façon)
Hors du sujet. GCC n'est pas un interprète.
Si vous avez écrit la mise en œuvre actuelle et que vous disez dans votre commentaire- il a:
Manipulation des symboles maladroits et nombreux Fuite de la mémoire
La réécriture en C ++ ne va pas vous aider. Essayez d'abord de comprendre pourquoi la mise en œuvre actuelle ne va pas. D'autre part, si vous n'êtes pas le développeur d'origine, choisissez la langue que vous connaissez le mieux et le port.
mise à jour: Je pense commentaire de STH explique correctement pourquoi de nombreuses langues sont implémentées dans C plutôt que C ++. Sur le sujet des réécrites complètes, Heed Les mots de Joel Spolsky .
C'est la chose: je ne suis pas le développeur original. L'interprète, tel qu'il se trouve, représente environ 10-15 ans d'évolution, pourquoi son code est si désordonné dans des endroits. Je suis assez convaincu que le seul moyen pratique de résoudre tous ses défauts est de la réécrire de zéro en C ou C ++; Mais je me demande pourquoi il y a, ou du moins semble être, aucun interprète populaire écrit en C ++. Mais alors, bien sûr, il y a toujours une première fois. ;-)
Je ne pensais pas que tu avais écrit l'original. J'ai mis à jour ma réponse un peu.
J'ai écrit un interprète en C ++ (après de nombreuses personnes en C au fil des ans) et je pense que C ++ est une langue décente pour cela. À propos de la mise en œuvre, je ne reviendrais que dans le temps et je modifierais mon choix de mettre en œuvre la possibilité d'avoir plusieurs interprètes différents fonctionnant en même temps (chacun multithreau) simplement parce qu'il a fait le code plus complexe et c'est quelque chose qui n'a jamais été utilisé. La multithreading est assez utile, mais plusieurs instances de l'interprète étaient inutiles ...
Cependant, mon grand regret est en effet le fait J'aurais tout simplement dû utiliser Python initialement à la place (ou Lua ou tout autre interprète prêt qui peut être facilement intégré et qui a une licence raisonnable) ... ma seule excuse pour cela est que je ne savais pas à Python ou Lua à cette époque.
En écrivant un interprète est une chose amusante à faire en tant qu'exercice de programmation, je vous suggère d'éviter de vous écrire pour la production, en particulier (ne le prenez pas personnellement) si les soins que la complexité de bas niveau nécessite de votre portée (je trouve par exemple la présence de plusieurs fuites de mémoire assez choquantes).
C ++ est toujours un langage de niveau bas et pendant que vous pouvez obtenir de l'aide, par exemple sur le côté de la manipulation de la mémoire, l'hypothèse principale Si vous avez manqué cette hypothèse de code 100% correct pour C (une langue beaucoup plus simple), je ne vois pas comment pouvez-vous être confiant que vous écrirez du code correct en C ++ (un monstre de complexité en comparaison). Je soupçonne que vous allez finir avec un autre interprète buggy que vous devrez jeter.
Je ne suis pas d'accord sur l'écriture de buggy en C ++. C ++ est TypeAfe (no vide * autour) et permet aux idiomes telles que RAII de gérer les ressources. Ces 2 caractéristiques facilitent la rédaction de code non-buggy à mon avis. Vérité à raconter, je pense que plus les caractéristiques d'erreur d'erreur sont effectivement viennent de c ...
Désolé mais je pense que vous êtes complètement faux à ce sujet. C ++ Le plus gros problème est la complexité et cela ne provient pas de C. Un problème grave est que cela peut regarder comme une langue de haut niveau, tout en étant ce n'est pas le cas, et si vous ne comprenez pas L'implication alors vous allez souffrir beaucoup avec C ++. Il est très facile d'écrire du code C ++ qui a l'air bien et que c'est à la place une bombe de temps de ticking ... Par exemple, v.push_back (v.back ()); à ajouter à un vecteur non vide une copie du dernier élément. En C ++, de tels pièges sont nombreux. Et c'est sûr que ce n'est pas une faute K & R.
Eh bien, je n'ai pas écrit l'interprète à l'origine; J'ai "adopté" de quelqu'un d'autre, tant de fuites de mémoire et d'autres problèmes étaient déjà présentes. J'ai réussi à enlever certains, mais dans l'ensemble, toute la mise en œuvre est toujours un gros gâchis - non pas parce que l'auteur original était un mauvais programmeur, mais comme l'interprète représente plus de dix ans d'évolution.
@THOMAS Les choses sont alors différentes ... j'essaierais de comparer x = (coût de la réécriture et de re-déboguer + coût futur pour les scripts en raison de la mauvaise langue) avec y = (coût d'intégration de python et de la conversion de scripts (ou d'écrire un convertisseur) + formation des programmeurs). C ++ pour la rédaction d'un interprète est à mon avis, car c ... Par exemple, les exceptions C ++ sont dans un interprète agréable à utiliser pour les erreurs d'exécution car il existe une "limite" logique claire sur l'état (pouvant attraper et avaler une exception Dans un programme général «Sprinkled State» C ++, le programme est très difficile à faire correctement).
Tamarin - L'interpréteur d'ECMAScript Adobe et Mozilla est écrit en C ++. Être celui pour lequel l'auteur de langue originale a la responsabilité, il pourrait être considéré comme le principal (IIRC la mise en œuvre de la référence de la CECMA est écrite dans OCAML, mais qui n'est pas réellement utilisée, sauf comme une référence)
Le moteur JavaScript Google Chrome V8 implémente ECMA-262 et c'est extrêmement rapide. Peut-être que vous pourriez le réécrire à C ++, mais vous ne réfléchissez à d'autres fonctionnalités telles que Mettre en œuvre une spécification de byTecode réécrit à la place de vos automatises en C ++. Réécrivez cela aidera simplement à organiser le code (qui est une grande chose pour le travail de groupe), mais rien de performance.
Oui, beaucoup sont. IIRC Le hotspot Java VM est écrit en C ++, Haskells GHC, ...
Autant de personnes ici ont noté, vous devriez vraiment consulter LLVM , c'est une boîte à outils pour la construction compilateur, interprète et machines virtuelles. Fondamentalement, vous faites le travail frontal, (c'est-à-dire l'analyse de votre langue + une analyse sémantique + de Codegen dans LLVM IR) et LLVM vous donnera immédiatement votre immeuble pour différentes plateformes, JIT, Optimisation, Compilation du code natif, ... Il dispose également de certains outils d'analyse et de traitement des erreurs et de la notification des erreurs (mais peut-être que cela fait partie de la sous-projet de clang.)
Remarque: tout cela est la connaissance d'une seconde main. AFAIK SEULEMENT UNE PARTIE ou la mise en œuvre de la référence est écrite dans HASKELLL, afin de générer des programmes optimisés dont vous avez besoin soit d'un backend de GCC ou de LLVM, qui est ensuite écrit respectivement en C ou C ++. Voyez ici: Fast Haskell en utilisant LLVM
Le compilateur GHC est écrit à Haskell, le système d'exécution de GHC est écrit en C, pas C ++.
La mise en œuvre Java de Sun semble être écrite en C ++ surtout.
Si des fuites de mémoire sont votre seul problème avec votre programme actuel, essayez-y Valgrind. Je n'ai jamais eu de fuite de mémoire dans mon logiciel que Valgrind ne pouvait pas te retrouver pour moi. En fait, il a sauvé mes fesses sur tant d'occasions.
Voici un tutoriel
Valgrind est un outil très utile, mais dans l'interprète, j'ai adopté (1) les fuites de mémoire nécessiteraient des corrections "radicales" extrêmes, des corrections "radicales", qui me demanderaient de réécrire de toute façon et de réécrire les parties du programme. (Potentiellement, causant des pointeurs suspendus, etc.), et (2) des fuites de mémoire ne sont pas le seul problème; Il existe une pile de modifications apportées à la manipulation des symboles que je veux faire et que le système existant est trop compliqué pour changer en toute sécurité, si cela a du sens.
Je ne pense pas que je puisse (ou que je veux) donner une couverture "oui". Je pense que c'est une question de pragmatisme combiné à des besoins de la langue individuelle et dépend également de la question de savoir s'il s'agit d'une langue compilée (ou d'une compilée de bytecode) ou interprétée, ou ...
Si vous essayez d'écrire du code multiplate-forme, vous constaterez que le dénominateur commun le plus bas est généralement un compilateur C (en raison de différentes architectures de la CPU, des assembleurs ne conviennent pas au déploiement de nombreuses plates-formes). Étant donné que C ++ a été codé pour s'asseoir sur la plupart des infrastructures C (comme l'utilisation de Nom Manglling pour s'adapter aux surcharges de type dans quelque chose qu'un liant C comprend), il s'agit généralement du langage OO le plus bas-dénominateur qui est disponible, même sur des systèmes embarqués. Cela en fait un choix populaire pour les personnes qui souhaitent écrire leur langue de haut niveau et maintenable.
En outre, la plupart des langages de programmation ont une raison d'exister, veulent résoudre des problèmes de manière différente (mieux signifie nécessairement différents, après tout), ce qui signifie qu'ils ont des besoins assez inhabituels concernant ce que leur code doit pouvoir faire, Et n'utilisez pas beaucoup d'installations de soutien une autre offre de langues de mise en œuvre, car elles n'auraient pas assez de contrôle. Donc, étant donné, vous voudrez réimplément beaucoup d'E.g. Le modèle d'objet et les types de données de toute façon, les aspects de bas niveau de C ++ sont un avantage.
Cela dit, de nombreuses langues commencent par leur première version écrite en C ++, un premier compilateur simple par exemple, puis écrivez la prochaine version dans cette version simple ("bootstrapping"). Cela présente l'avantage de pouvoir utiliser votre propre langue pour l'étendre. Pour le porter, ils ne modifient ensuite que leur compilateur à croiser sur la plate-forme souhaitée, puis construisez le compilateur avec ce compilateur croisé et le résultat est une version native de la langue complète de la nouvelle plate-forme.
Les langues qui ont tendance à ne pas faire cela sont généralement principalement les langages de script, qui ont tendance à rester comme interprété comme interprété de langues mises en œuvre (bien que d'autres ont mentionné des exceptions populaires).
Une autre raison commune de choisir C ++ est l'infrastructure existante. Par exemple. Si vous souhaitez vous lier à des cadres système existants, vous devez souvent déposer à C ++ ou si vous souhaitez tirer parti des backendances du compilateur existant (comme LLVM, qui est écrit en C ++), ou même s'ils n'utilisent que c, souvent C ++ est le langage de mise en oeuvre le plus approprié qui puisse facilement parler aux parties C d'un système.
La question que vous voulez vous poser est probablement: quels sont mes besoins et quelle langue convient le mieux à ceux?
Certaines langues sont simplement des préprocesseurs sur une autre langue (C ++ et Objective-C ont tous deux commencé comme préprocesseurs sur c). Ils ajoutent leur propre syntaxe ou fonctionnalités, traduisent ceux-ci dans la langue de mise en œuvre, puis compilez ce code modifié à l'aide d'un compilateur existant. Si une langue utilise déjà tout ce que vous voulez, cela peut être une meilleure approche, et vous permet de tirer parti de l'expérience des ingénieurs travaillant sur cette autre langue, combinant vos heures de travail dans plus de chez vous.
Votre interprète fonctionne? Est stable? Utilisé par les gens? Pourquoi vous réécrire tout?
Si vous avez déjà une implémentation C, c'est une excellente raison de ne pas la réécrire en C ++.
Certes, mon interprète fonctionne, mais il y a un certain nombre de problèmes avec cela - en particulier, la manipulation des symboles maladroits et de nombreuses fuites de mémoire. Ces défauts sont tels que je crois que la meilleure façon de les résoudre est de réécrire l'interprète à partir de zéro. Étant donné que les deux seuls deux prétendeurs réels de la langue de réécriture sont C et C ++, je me demande si C ++ serait la meilleure langue à mettre en œuvre l'interprète, en considérant qu'elle fournit (ce qui semble être) des installations plus intuitives pour la gestion de la mémoire et la chaîne En traitement.
+1 pour ne pas penser que c et c ++ sont fondamentalement les mêmes.
Savez-vous C ++ aussi bien que vous savez C. Connaissez-vous C ++ assez bien pour écrire votre programme sans dépenser une grande partie de votre temps d'apprentissage des idiomes et des meilleurs moyens d'atteindre votre objectif? Essentiellement, allez-vous apprendre C ++ tout en faisant cette réécriture? Si oui, alors vous devez vous en tenir à votre implémentation C, sauf si vous souhaitez réécrire potentiellement une fois que vous savez ce que vous faites.
Si vous avez une implémentation de travail C, c'est un excellent point de départ pour la réécrire en C ++.
Vous êtes peut-être intéressé par ces diapositives: airs.com/ian/cxx-slides.pdfled/a >
Votre première question n'est responsable que par référence au code source. J'ai écrit un interprète de production en C dans les années 1980 et si je le faisais aujourd'hui, je le ferais certainement en C ++ ou même Java.