UnderC : un interpréteur c++

Posté par (page perso) . Modéré par Nÿco.
Tags :
0
19
juin
2003
Technologie
UnderC est un interpréteur C++, ce qui a le mérite d'être original. De taille modérée (les binaires font autour de 400ko), il implémente, aux dires de son auteur, une bonne partie du standard C++ (les templates n'étant que très partiellement supportés), et se destine autant à l'enseignement du C++ qu'à une utilisation en tant que langage de script. Il permet d'appeler facilement des fonctions/classes issues d'une bibliothèque C ou C++ (modulo les problèmes d'ABI de g++ j'imagine..), et à terme pourrait devenir un environnement de développement assez intéressant (en particulier pour les gains sur le temps de compilation).

Aller plus loin

  • # Re: UnderC : un interpréteur c++

    Posté par . Évalué à 10.

    Mouaih.... Je suis un peu sceptique.

    Dans un but d'enseignement, les programmes ne font pas des millions de lignes et le temps de la compilation reste assez négligeable.

    De mon côté, je suis un adepte de la recompilation fréquente plutôt que de coder 200 lignes d'un coup avant de tester, et je n'ai jamais été frustré par les temps de compilation !

    D'un autre côté, le C++ est déjà extrêment évolué (trop ?) pour du scripting, et la rapidité liée à la non compilation devrait également se retrouver dans la facilité / l'API du langage (par exemple, en perl ou en bash, voir en PHP, on arrive à ses fins rapidement alors qu'en C++, il faudra généralement plus de lignes, surtout si on ne trouve pas un objet existant répondant au problème.

    Je trouve çà un peu gadget, et de vouloir forker le C++ en un langage interprété n'a pas trop de sens à mon avis.
    • [^] # Re: UnderC : un interpréteur c++

      Posté par (page perso) . Évalué à 4.

      Y'a quand même un truc qui pourrait être intéressant : Faire des sessions interactives. On peut déjà faire un peu ça en gdb avec "p fonction(argument)", mais c'est très limité.
      • [^] # Re: UnderC : un interpréteur c++

        Posté par (page perso) . Évalué à 0.

        > Y'a quand même un truc qui pourrait être intéressant : Faire des sessions
        > interactives.

        OUI ! Ca c'est bien !
        Il n'y a rien de tel pour l'apprentissage d'un langage et même pour la productivité. Ces environnements où on peut tout essayer tout de suite... raah/lovely
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 2.

        J'ai vu un pote patcher son code pendant l'exécution du programme.
        Bon, ok, il le faisait avec un compilo proprio et loin d'etre libre du tout (MSVC vous aurez deviné :p), mais ne sachant pas utiliser gdb, et n'ayant pas encore trouvé d'IDE qui me convienne (nan, je voudrais autre chose qu'EMACS ou KDEVELOP), je dois avouer que c'est impressionnant de debuguer et de pouvoir même modifier le code lors de l'exécution...
        L'interprétation ne pourrait pas permetre des choses dans le genre ?
        (et si quelqu'un sait comment patcher du code en direct avec un compilo C/C++ libre, ça m'interesserai, dites-moi le que je cherche un peu, car là, j'ai pas encore cherché (manque de temps))
        • [^] # Re: UnderC : un interpréteur c++

          Posté par . Évalué à 2.

          On peut aussi le faire en java. Avec eclipse et un JDK 1.4, on peut modifier le contenu d'une méthode à l'éxécution.
    • [^] # Re: UnderC : un interpréteur c++

      Posté par . Évalué à 1.

      Le scripting C++ existe déjà avec Qt Script for Applications.
      Il suffit de dériver de QObject est tous les slots sont disponibles pour les scripts. La version 1.0 en est à beta5, mais ça a l'air vraiment prométeur.
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 5.

        Le scripting C++ existe déjà avec Qt Script for Applications.

        Oui, mais non, QSA, c'est de l'ECMAScript.
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 1.

        oui mais non pas tout a fait, QSA n'est pas fait pour être un language de script à part entière -bien qu'en développant une application Qt ne faisant qu'interprété et disposant d'objets de toutes les classes, autrement dit faire un interpreteur comme l'est l'interpréteur Python ou perl-, QSA est fait pour rendre scriptable une application en C++, aisni permettre à un utilisateur d'étendre l'appli en faisant des scripts -pouvant être puissants, d'accord, car disposant d'un grand nombre de classes Qt de facon native, mais d'autres ne sont disponibles que si le développeur de l'application le permet-.
        conclusion: QSA n'est pas un interpréteur C++ au sens propre du terme -il y en a forcément un-, mais un moyen d'extention d'une application C++
    • [^] # Re: UnderC : un interpréteur c++

      Posté par (page perso) . Évalué à 8.

      Au contraire de ce que tu dis, un interpreteur est tres tres partique. Pour travailler souvent en python, je peux te dire que j'apprecie. Les gros avantages que j'y vois:
      - meme si la recompilation est rapide, quand il n'y en a pas, c'est encore plus rapide
      - ca permet de tester vite fait des petites construction. Chez moi j'ai un repertoire pour faire ce genre de tests
      - en python en tout cas, ca me permet de verifier rapidement des trucs sans en passer par le necessaire printf. Typiquement, quand j'ecris des regexps, je passe 10 minutes a les valider dans l'interpreteur.
      - une des lourdeurs du C++, c'est la gestion du Makefile. Je ne sais pas comment fonctionne cet interpreteur mais s'il arrive a s'en affranchir, il rendre certainement le developpement plus rapide.
      - quand on debuge, c'est pratique d'avoir une session interactive pour valider le comportement de certaines fonction. gdb est tres limite de ce cote la.

      A mon avis, ca ne peut que faciliter l'apprentissage du C++ et c'est tout a fait complementaire d'un compilateur en phase finale. Cela dit, le C++ a une syntaxe et une grammaire tres compliquee qui doit le rendre lourd a utiliser sous un interpreteur. Je lui prefere des langages a la syntaxe plus legere: python!!!!
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 1.

        - une des lourdeurs du C++, c'est la gestion du Makefile. Je ne sais pas comment fonctionne cet interpreteur mais s'il arrive a s'en affranchir, il rendre certainement le developpement plus rapide.
        make c'est pour automatiser la compilation, donc cet interpréteur ne l'utilise surement pas. Mais il doit utiliser un autre système pour aller charger les différents fichiers du programme.

        Je lui prefere des langages a la syntaxe plus legere: python!!!!
        Oui, bof.
        J'ai commencé python il y a quelques semaines pour un projet (libre bien sur). Il y a des trucs très sympa dans ce langage, notament les nombreuses fonctions de la bibliothèque, les listes et les dictionnaires (génial les dictionnaires!).
        Mais par contre je déteste sa façon de faire des blocs!
        Et puis il manque l'instruction select()case:, c'est pas joli de faire ça avec plein de elif.
        Ah et aussi le ++ me manque ;-) et j'apprécie moyennement sa façon de faire un for mais j'aid éjà constaté que c'était très chouette dans certaines conditions.
        • [^] # Re: UnderC : un interpréteur c++

          Posté par . Évalué à 2.

          Ah et aussi le ++ me manque ;-)
          Ben appelle ce langage Python++ si ca te manque tellement!

          Pas la peine d'essayer de taper, chuis déjà dehors...

          "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

        • [^] # Re: UnderC : un interpréteur c++

          Posté par (page perso) . Évalué à 3.

          je déteste sa façon de faire des blocs!
          J'avais lu sur je ne sais plus quel newsgroup que ceux qui n'aimaient pas le fait d'utiliser l'indentation pour marquer les blocs changaient généralement d'avis après une utilisation plus prolongée du langage :) Ça ne doit pas être valable pour tout le monde, mais il semblerait que ça soit courant.

          il manque l'instruction select()case:, c'est pas joli de faire ça avec plein de elif
          elif n'est pas la seule possibilité. Tu peux aussi faire un dictionnaire dont les clés sont les cas du select et les valeurs sont les noms de fonctions à appeler (ou plus gruik, une chaine contenant les instructions, que tu passes à eval() :p)

          le ++ me manque ;-)
          moi aussi :)
          Mais le python veut avant tout rester un langage clair, et le ++ mal utilisé peut rapidement donner des trucs illisibles. C'est également la raison pour laquelle l'opérateur ternaire n'a pas été intégré.
          Le python sépare affectation et valeur, beaucoup plus que le C ou le C++. Faire un print a+=3 provoque une erreur de syntaxe : a+=3 n'a pas de valeur en lui-même.

          j'apprécie moyennement sa façon de faire un for
          Ca dépend comment tu prends le langage. Les listes et tuples sont très largement utilisés, et un for sert généralement à parcourir une série de données. En python, tu auras tendance à mettre cette série de données dans une liste... tout se tient !
          C'est chouette dans quasi toutes les conditions :)
          [Note pour les non pythoniens : for element in liste : print element]

          Voilà, il fallait bien que je défende le langage qui a fait que je n'aime plus les autres :)
          • [^] # Re: UnderC : un interpréteur c++

            Posté par . Évalué à 0.

            J'avais lu sur je ne sais plus quel newsgroup que ceux qui n'aimaient pas le fait d'utiliser l'indentation pour marquer les blocs changaient généralement d'avis après une utilisation plus prolongée du langage
            Alors à condition de ne plus en utiliser d'autres.

            C'est également la raison pour laquelle l'opérateur ternaire n'a pas été intégré.
            Oui, lui aussi il me manque ;-)

            Faire un print a+=3 provoque une erreur de syntaxe : a+=3 n'a pas de valeur en lui-même.
            Ah?
            On peut faire des +=, je n'avais pas vu ça dans la doc (celle disponible sur le site de python). Bonne nouvelle :-)
            • [^] # Re: UnderC : un interpréteur c++

              Posté par (page perso) . Évalué à 1.

              Alors à condition de ne plus en utiliser d'autres.
              Si, mais ce sont alors les autres qui deviennent affreux :)

              Pour l'opérateur ternaire, et parce qu'un exemple est plus simple :
              >>> a = 1==1 and "vrai" or "faux"
              >>> a
              'vrai'
              >>> a = 1==2 and "vrai" or "faux"
              >>> a
              'faux'

              Attention, ca ne marche logiquement pas si on veut utiliser 0 (ou toute valeur qui évalue à faux) à la place de "vrai".
        • [^] # Re: UnderC : un interpréteur c++

          Posté par (page perso) . Évalué à 1.

          > Python et les blocs:
          Moi je trouve ca genial parce que ca permet une syntaxe beaucoup plus legere. Python n'utilise que deux elements syntaxiques: les parentheses et l'indentation. Ca donne des programmes tres lisisbles et tres rapide a taper. Le C/C++ se tapes des accolades, des parentheses, des point-virgules. C'est relativement lourd. Mais ca fait tellement longtemps qu'on en fait qu'on ne les voit plus.


          > ++

          Le ++ est une construction pratique du C qui permet de faires des programmes plus courts du genre de while(i--) { ... }. Mais c'est completement a l'oppose de la philosophie de python (clarte, simplicite) car il y a deux effets caches: une incrementation delayee et un retour de valeur. Tu peux te rabattre sur le +=.
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 2.

        >Je lui prefere des langages a la syntaxe plus legere: python!!!!

        <mode vantard>
        ouais bof... perso je réecris en ce moment même une implémentation de xmms en brainfuck. ça c'est pas du langage de petzouille!
        bon j'en suis à afficher le titre xmms dans la fenetre. mais c'est super prometteur.

        </mode vantard>


        ok..... ----------------------> [-]
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 2.

        "une des lourdeurs du C++, c'est la gestion du Makefile. Je ne sais pas comment fonctionne cet interpreteur mais s'il arrive a s'en affranchir, il rendre certainement le developpement plus rapide. "


        ==> d'où l'intérêt d'IDE comme Kdevelop (3.0) qui automatisent complètement la gestion des makefile... A essayer absolument.
        • [^] # Re: UnderC : un interpréteur c++

          Posté par . Évalué à 4.

          make est la pour simplifier la vie pas pour la compliquer...
          perso je me suis fais mes makefiles 'generic' et a chaque nouveau projet j'ai pas de nouveaux makefile a refaire (juste recreer un repertoire avec les headers et les src dedans). Bref tout ca pour dire que make est pas vraiment un probleme dans le processus de developpement.
    • [^] # Re: UnderC : un interpréteur c++

      Posté par . Évalué à 1.

      Au contraire j'ai trouvé ça très intéressant. Quand on fait un programme compilé en C++ il me semble plus cohérent d'utiliser comme langage de script associé du C++ également plutôt qu'un autre langage.
      Je n'ai pas regardé en détail ce under c, mais on peut imaginer que ça simplifie considérablement le lien entre le code compilé et le langage de script puisque les définitions des classes sont les même : pas de problème pour faire le lien entre les deux.
      Je m'explique : par exemple j'ai un objet d'une classe Toto dans mon programme. Pour que cet objet soit accessible par script, je n'ai pas besoin de redéfinir Toto dans le langage du script, puisque justement c'est aussi du C++. D'où un gain de temps.
      Comme je disais, je suis pas sûr que under C permette ça facilement, mais si c'est le cas, ou si un jour c'est le cas, ça rend très intéressant cet interpréteur.
  • # Re: UnderC : un interpréteur c++

    Posté par (page perso) . Évalué à 7.

    Bof,
    j'avoue que je ne vois pas vraiment l'utilité (mais bon, ce n'est que mon point de vu).
    Si les templates ne sont que très légèrement suportés, à quoi bon ? Il existe Java pour çà, et depuis le temps que ce language existe il commence à être robuste.
    Pour moi, le C++ est et doit rester un language compilé ...
    • [^] # Re: UnderC : un interpréteur c++

      Posté par . Évalué à 7.

      Les avantages d'avoir un interpréteur à la place d'un compilo sont nombreux. Surtout en phase de développement et en phase de tests. L'interet est de pouvoir tester très facilement tes fonctions directement après les avoir écrites. Ca facilite grandement les tests unitaires. Le gros inconvénient du c++ est d'imposer un main par programme (contrairement à Java qui permet d'en faire un par classe) ce qui complique énormément les tests unitaires.

      Pour t'en convaincre, essaie des langages fonctionnels, qui offrent pour la plupart des interpréteurs.
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 2.

        Justement, pour des tests unitaires (et donc je suppose pour de _petits_ bouts de code), la difference entre le temps de compilation + execution et le temps d'interpretation sera quasi nulle, donc pourquoi se priver de la compilation, qui elle au moins supportera toutes les acrobaties de code que tu auras pu faire!

        "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

        • [^] # Re: UnderC : un interpréteur c++

          Posté par . Évalué à 2.

          Et de plus la compilation peut déjà repérer plein de "bêtes" erreurs de syntaxe et autres caractères qui sont restés dans le clavier, alors qu'avec l'interprétation il faut faire des tests qui vont exécuter toutes les parties de ton code pour qu'il trouve ces erreurs. Ce n'ets qu'à moitié vrai pour des langages semi-compilés comme java où python.
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 6.

        Bof, bof, bof...

        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 . Évalué à 1.

          > Qui dit que l'interpreteur va se comporter de la meme facon que le compilateur ?

          C'est clair qu'il faudrait une option "--fake-gcc-version=<x.y.z>".



          Voui, voui, suis déjà oh-qu'ai-je-sorti...
      • [^] # Re: UnderC : un interpréteur c++

        Posté par . Évalué à 1.

        >Les avantages d'avoir un interpréteur à la place d'un compilo sont nombreux

        > Pour t'en convaincre, essaie des langages fonctionnels, qui offrent pour la plupart des interpréteurs.

        J'ai l'impression que tu melanges interpretation, compilation et environment interactif.

        Un langage interprete est un langage qui n'est pas compile. Un langage compile produit du code machine. Un environnement interactif te permet de taper des expressions ou des programmes complets sans besoin de quitter ton environnement, car evaluer sur place (genial pour tester sans tout recompiler our interpreter).

        Des implementations de Common Lisp (libre ou commerciales) souvent disposent d'un interpreteur et/ou d'un compilateur *et* d'un environnement interactif.

        Je connais au moins une implementation qui compile a la volee les expressions tapees interactivement. Pas forcement utile, car tu peux compiler une fonction par ex en tapant (compile 'fonction)
        • [^] # Re: UnderC : un interpréteur c++

          Posté par (page perso) . Évalué à 1.

          C'est souvent lié quand même. L'interprête parse le programme et charge une structure en mémoire. Du coup, il est très facile de faire un environnemnet interactif.

          En général, quand un environnemnet interactif dit qu'il "compile" un programme, il le compile en byte-code (d'ailleurs, pour les dérivés de lisp, c'est assez rare d'avoir de la vraie compilation en code natif), qui est ensuite interprêté. Pour faire de la vraie compilation à la volée, c'est plus difficile, vu qu'il faut charger dynamiquement un morceau de binaire, faire l'édition de liens, etc. Ca casse une bonne partie des optimisations (inlining, ...). Je ne connais pas d'environnement interactif qui compile réellement le code en code natif.
          • [^] # Re: UnderC : un interpréteur c++

            Posté par . Évalué à 1.

            Les implementations de Common Lisp que j'utilise (cmucl ou lispworks) compilent en natif. J'en connais plein d'autres qui le font aussi: sbcl, allegrocl, mcl, corman lisp etc...
            Ces implementations compilent toute a la volee quand tu tapes (compile 'function).

            Corman Lisp compile a la volee en code natif quand tu tapes une expression interactivement.

            Je connais au moins une seule implementation qui compile en byte-code: Clisp, qui est d'ailleurs tres portable et est curieusement tres rapide en calcul numerique.
        • [^] # Re: UnderC : un interpréteur c++

          Posté par . Évalué à 2.

          Juste pout être sur d'avoir bien compris la différence entre un compilo et un interpréteur, corrigez moi si je me trompe.

          Pour le compilo :
          ~~~~~~~~~~
          Source ---> ByteCode/SDD dédiée ---> code natif

          le tout en une seule passe (compilation + edition de lien)

          Un interpréteur :
          ~~~~~~~~~~
          Le source est lu et transformé à la volée en Bytecode puis en code natif pour être executé.

          Donc l'unique différence entre un interpréteur et un compilateur est le moment où est fait la "traduction" (cad à l'execution ou avant pdt la compilation)

          Le gros intéret des interpréteurs est donc de pouvoir réaliser des environnements interactifs. D'où le raccourcit interpréteur = environnement interactif. Cela n'empeche pas de pouvoir se passer de cet environnement et de crééer un executable ki s'interpretera ou qui sera compilé (ex : ocaml)

          L'inconvenient est de limiter le nombre d'optimisations puisque l'interpreteur n'a qu'une vision locale du code, celle du bloc d'instructions en bytecode en cours de traduction.

          Quand a un environnement interactif effectuant de la compilation à la volée j'appele ça bash + gcc.

          Désolé pour les fôtes, Bonne nuit ;-)
          • [^] # Re: UnderC : un interpréteur c++

            Posté par (page perso) . Évalué à 2.

            Ben non, justement, dans un vrai interprête, y'a jamais de code natif. Le code de l'interprêteur ressemble à ça :

            switch(instruction) {
            case INSTRUCTION1:
            exec_inst_1(); break;
            case INSTRUCTION2;
            ....;
            }

            Un autre intérêt de la chose est que c'est portable, alors que la partie génération de code d'un compilo doit être réécrit pour chaque plateforme. (Ici, on s'en fout, vu que g++ existe déjà sur quasiment toutes les plateformes.)

            Pour ton environnement interactif à base de bash, essaye de lancer ton programme, de l'arrêter au milieu d'une fonction, de changer la définition d'une autre fonction pendant ce temps là, de continuer un peu l'execution, de créer une nouvelle classe, d'appeler une méthode de cette classe, puis de terminer l'execution. Le tout sans redémarrer le programme. (note : C'est à peu près ce que font les utilisateurs d'Emacs quand ils trifouillent leur config. On va pas redémarrer Emacs à chaque fois ...)
    • [^] # templates ?

      Posté par (page perso) . Évalué à 1.

      ça fait 2 ans que je fais du C++ avec BeOS, et j'ai jamais (ok, une fois, mais ça a foiré) utilisé des templates.
      Je sais je sous-utilise C++, mais franchement, BList c + sympa, je peux pas blairer la syntaxe des templates.
      • [^] # Re: templates ?

        Posté par . Évalué à 1.

        En même temps le C++ de BeOS est particulierement pauvre de ce coté la: pas de templates, pas d'exceptions... Du C avec des classes, quoi. Honnètement c'est ce qui m'a dégouté de la programmation sous Be: à quoi ca sert d'avoir une belle API C++ et de le crier sur tous les toits si ca n'est finalement qu'une API très pauvre point de vue C++? Alors je sais bien qu'à l'époque où ca a été écrit, le C++ n'était pas aussi avancé, tout ca tout ca. Mais n'empèche que c'est pas le truc que je brandirais en référence du C++ propre :)

        Et puis l'inconvénient majeur des BLists, pour autant que je m'en souvienne, c'est qu'il ne peut pas forcer une utilisation homogène: on peut toujours mettre n'importe quoi dedans. Chose qu'on ne peut pas faire avec une std::list<mon_joli_type>.

        On a deja eu cette discussion sur BeShare il y'a un bail: les templates c'est le futur (du moins le futur des langages fortement typés). Autant je ne supporte plus guère le C++, autant les templates c'était vraiment ce que j'aimais bien dedans (avec le polymorphisme paramétrique).
  • # Re: UnderC : un interpréteur c++

    Posté par . Évalué à -5.

    merci freshmeat n'est ce pas?

    UnderC C++ Interpreter 1.2.4 (Development)
    by bolshoi - Thursday, June 19th 2003 01:46 PDT

    About: UnderC was designed as a compact fast interpreter which does most of the ISO standard. It does templates, and comes with 'pocket' versions of the standard library classes like string, vector, map, etc. It is very straightforward to load functions from shared libraries using a simple pragma and an external "C" directive. UnderC is a fully interactive system, so single lines of code can be quickly evaluated and tested.

    Changes: In this version, the UnderC Reflection Interace (UCRI) allows UnderC programs to access their own metadata. Some preliminary documentation is available for using the libraries and using UnderC as a shared library to add C++ scripting to your own applications.

    http://freshmeat.net/branches/20675/(...)


    aujourd'hui en première page.


    Faut citer tes sources s'il te plait, sinon c'est du pillage
    • [^] # Re: UnderC : un interpréteur c++

      Posté par (page perso) . Évalué à 2.

      euh ben bien sûr que merci freshmeat, mea maxima culpa, je me flagelle avec une tronçonneuse et je remercie pour cette news:
      - freshmeat que j'ai honteusement violé et pillé et sans qui je n'aurais pas vu passer la version 1.2.24 de underc
      - l'auteur de underc qui s'est cassé le cul à passer une annonce sur freshmeat.
      - mon chef de m'avoir foutu la paix cet après-midi ce qui m'a permis de glander sur freshmeat
      - le modérateur sans qui cette news n'aurait pu être modérée
      - plop & folop sans qui je serais en train de râler après outlook
      - mon papa et ma maman sans qui je ne serais pas là
  • # Re: UnderC : un interpréteur c++

    Posté par (page perso) . Évalué à 2.

    moi je suis l'auteur d'un interpréteur C++, je vous envoie la version 1.0.1 en exclusivité:

    ---snip here---
    #!/bin/sh
    g++ $1
    ./a.out
    ---snip here---
    • [^] # Re: UnderC : un interpréteur c++

      Posté par . Évalué à 1.

      Et pour l'interprétation interractive on fait comment?
    • [^] # Re: UnderC : un interpréteur c++

      Posté par . Évalué à 3.

      > je vous envoie la version 1.0.1 en exclusivité

      Oups, t'as oublié le ChangeLog...

      * since 1.0.0:
      - fixed the weird bug which prevent interpretation when ./ was not in $PATH
      - removed dependency on zsh


      Et le TODO:

      * for 2.0 release:
      - command line options support
      - remove the "./a.out: No such file or directory" message at the end of the interpreter errors
      • [^] # Re: UnderC : un interpréteur c++

        Posté par (page perso) . Évalué à 2.

        voilà la version 2.0 vient d'être releasée

        #!/bin/sh

        if [ $# -eq 0 ]
        then
        echo "ouah++ v2.0 - Vous devez indiquer un source C++"
        else
        g++ $* &> /dev/null
        if [ $? -eq 0 ]
        then
        ./a.out
        else
        echo "ouah++ v2.0 - Une erreur s'est produite"
        fi
        fi
  • # Re: UnderC : un interpréteur c++

    Posté par . Évalué à 1.

    >une bonne partie du standard C++
    Je peux le trouver où ce soit disant standard?
  • # Re: UnderC : un interpréteur c++

    Posté par (page perso) . Évalué à 2.

    À voir aussi : TCC (Tiny CC) par Fabrice Bellard, l'auteur de LZEXE pour ceux à qui ça dit quelque chose.

    http://fabrice.bellard.free.fr/tcc/(...)

    Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

    • [^] #

      Posté par (page perso) . Évalué à 1.

      également auteur de FFMPEG, LA source de codecs Libres de la communauté (utilisée par mplayer, vlc, aviplay, xine, ...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.