Sortie de TinyCC 0.9.26

Posté par (page perso) . Édité par Xavier Claude et Florent Zara. Modéré par Florent Zara. Licence CC by-sa
61
18
mar.
2013
C et C++

TinyCC est un compilateur C léger et rapide qui, en plus de ces qualités, a deux particularités originales :

  1. il permet de compiler et d'exécuter du code à la volée (option -run) ;
  2. en plus de l'exécutable, il est disponible sous forme de bibliothèque (libtcc) afin d'être embarqué dans d'autres programmes.

TinyCC a été écrit à l'origine par Fabrice Bellard, qui ne participe aujourd'hui plus à son développement. Les nouveaux développements sont assurés par une communauté de développeurs organisés autour d'une liste de diffusion et d'un dépôt Git dont l'une des branches est ouverte aux publications externes. Le vendredi 15 février 2013, l'un de ces développeurs, Thomas Preud'homme a annoncé la sortie d'une nouvelle version du compilateur, estampillée 0.9.26. Nous avons posé quelques questions à Thomas, dont les réponses figurent en deuxième partie de dépêche après l'exposé des nouveautés de cette version.

Sommaire

Modifications importantes depuis TinyCC 0.9.25

Ceci est une traduction de la note de version officielle.

Interface utilisateur

  • Option -MD/-MF (génération automatique de dépendances pour make) (Kirill Smelkov)
  • Option -pthread (identique à -D_REENTRANT -lpthread) (Henry Kroll III)
  • Options -m32 et -m64 pour réexécuter le compilateur croisé (Henry Kroll III)
  • Support par l'option -Wl de toutes les formes d'options supportés par GNU ld (Kirill Smelkov)
  • Ajout de la fonction tcc_set_options() à l'API de libtcc (grischka)

Plates-formes

  • Beaucoup d'améliorations pour les cibles x86-64 (Shinichiro Hamaji, Michael Matz, grischka)
  • Assembleur x86-64 (Frederic Feret)
  • Beaucoup d'améliorations pour les cibles ARM (Daniel Glöckner, Thomas Preud'homme)
  • Support des systèmes Windows CE PE ARM (Timo VJ Lahde)
  • Support de la convention d'appel des fonctions « ARM hardfloat » (Thomas Preud'homme)
  • Support de SELinux (Security-Enhanced Linux) (Henry Kroll III)
  • Support des systèmes Debian GNU/kFreeBSD (Pierre Chifflier)
  • Support des systèmes GNU Hurd (Thomas Preud'homme)
  • Support de MacOS X (tcc -run seulement) (Milutin Jovanovic)
  • Support des configurations multi-architectures (Thomas Preud'homme)
  • Support de la compilation hors-arborescence (Akim Demaille)

Fonctionnalités

  • Tableaux à longueur variable C99 (Thomas Preud'homme & Joe Soroka)
  • Étiquettes assembleur pour les variables et fonctions (Thomas Preud'homme)
  • STT_GNU_IFUNC (fonctions dont l'adresse est résolue par l'appel d'une autre fonction) (Thomas Preud'homme)
  • Plus de tests (tests2) (Milutin Jovanovic)

Interview de Thomas Preud'homme

Thomas Preud'homme, connu sur LinuxFR sous le pseudonyme robotux, termine actuellement une thèse au Laboratoire d'Informatique de Paris 6 (LIP6), intitulée « Communication inter-cœurs optimisée pour le parallélisme de flux ». Contributeur au projet Debian depuis plusieurs années, il est responsable de plusieurs paquets, dont TinyCC (paquet tcc), et est devenu développeur Debian depuis peu.

DLFP : Bonjour Thomas. Peux-tu nous en dire plus sur l'histoire de TinyCC ?

Je n'en sais pas beaucoup plus que ce qu'on peut trouver sur Internet. Tout a commencé sous la forme d'un bout de code soumis par Fabrice Bellard au concours international de code obscur IOCCC, appelé OTCC (pour Obfuscated Tiny C Compiler, minuscule compilateur C obscurci). Par la suite, Fabrice a ajouté le support du format de binaire ELF (Executable and Linkable Format) renommant au passage le programme en OTCCELF. Enfin, il a réécrit le compilateur sous la forme de TinyCC afin de le rendre plus lisible, améliorant au passage le support du C.

Le développement de TinyCC s'est arrêté plusieurs fois après que Fabrice ait cessé de maintenir TinyCC. Ce sont ces pauses dans le développement qui ont mené (à ma connaissance) au développement du fork de Rob Landley. Chaque fois, les changements apportés par Rob étaient réintégrées dans TinyCC relançant brièvement le développement de celui-ci. Lorsque cela se produisait, Rob cessait alors le développement, n'en ressentant plus l'utilité, ce qui provoquait une nouvelle pause dans le développement de TinyCC. Ce développement chaotique a eu raison de la patience de Rob qui a fini par ne plus vouloir contribuer à TinyCC. Il s'en est expliqué sur son site. Rob s'intéresse maintenant à la création d'une boîte à outils pour la compilation qui réutiliserait la partie génération de code de Qemu, supportant ainsi toutes les architectures que supporte Qemu.

Au fil des versions, TinyCC s'est étoffé : il supporte maintenant plusieurs architectures (x86 32 et 64 bits, ARM pour diverses conventions d'appel, Texas Instrument TMS320C67xx et .NET CLI), plusieurs plates-formes (Linux, Windows, (k)FreeBSD, et support partiel de Hurd et MacOS X).

DLFP : Qui contribue au développement de TinyCC ? La liste des contributeurs pour cette version comporte plusieurs dizaines de noms. Est-ce une habitude ? Le développement est-il essentiellement assuré par un noyau de contributeurs réguliers, ou les contributions ponctuelles sont-elles les plus fréquentes ?

Je ne sais pas très bien qui sont les contributeurs de TinyCC. Mon impression est que les contributeurs se divisent plus ou moins en deux catégories. Il y a d'une part ceux qui s'intéressent aux compilateurs : ceux-ci préfèrent TinyCC car sa petite base de code est plus facile à étudier et parce que la branche de développement est ouverte à tous, permettant de partager plus simplement leurs expérimentations. Ceux-ci sont plutôt des contributeurs réguliers. D'autre part, il y a ceux qui ont rencontré un bogue avec TinyCC et qui cherchent à le corriger. Cela peut se traduire dans des contributions importantes lorsque la personne rencontre plusieurs bogues ou que c'est un problème assez essentiel dans TinyCC. Il s'agit alors de contributions plutôt ponctuelles.

Le nombre de contributeurs pour cette version est exceptionnellement élevé. D'après l'historique, le nombre de contributeurs n'a cessé de croître, ce qui est plutôt encourageant. Cependant le nombre de contributeurs pour cette version s'explique aussi par la période particulièrement longue pour arriver à cette nouvelle version. Il a fallu 3 ans pour développer celle-ci, là où les versions précédentes ne prenaient qu'un an en moyenne.

DLFP : Tu as toi-même produit un certain nombre des changements qui ont mené à cette nouvelle version de TinyCC. Quand et comment as-tu commencé à contribuer ? Qu'est-ce qui t'intéresse particulièrement dans ce projet ?

J'ai commencé à m'intéresser à TinyCC un peu par hasard. Utilisateur de Debian depuis plusieurs années, je souhaitais commencer à contribuer en retour, en partie pour montrer ma reconnaissance sur tout ce que j'ai pu retirer de ce projet. Je connaissais Aurélien Gérôme, qui était sur le point de devenir développeur Debian, et il m'a proposé de maintenir TinyCC avec lui. Ce programme étant écrit dans mon langage de prédilection (le C) et étant intéressant pour moi, j'ai accepté. Je n'utilisais alors pas TinyCC et j'ai commencé à l'utiliser à cette époque.

Peu actif au début, j'ai fini par me retrouver tout seul à maintenir le paquet. La majeure partie des bogues, pour ne pas dire tous, étaient liés à des problèmes du logiciel et non de l'empaquetage. J'aurais pu me contenter de transmettre les bogues aux développeurs amont mais je ne pouvais résister à l'envie d'essayer de les corriger moi-même. J'ai donc commencé sur ceux qui correspondaient à des problèmes bien isolés.

J'ai pris beaucoup de plaisir à corriger ces bogues car je n'avais jamais suivi de cours de compilation et ai donc appris en lisant le code. TinyCC n'est pas le meilleur exemple en la matière certes, mais le code est relativement petit et donc plus simple à comprendre. Le code est d'autant plus simple qu'il n'y a pour ainsi dire pas d'optimisation du code généré. Cela rend évidemment le code moins efficace mais rend la compilation plus rapide et surtout, pour ce qui nous concerne, le code de génération plus simple à lire. De plus, je suis globalement intéressé par tout ce qui est bas niveau : noyaux, compilateurs, chargeurs dynamiques, etc. Travailler sur TinyCC m'a permis d'apprendre beaucoup dans ce domaine.

DLFP : Comment en es-tu venu à être responsable de la publication de cette version ? Penses-tu t'occuper des prochaines versions également ?

Un jour, on m'a soumis un rapport de bogue visant à supporter une nouvelle convention d'appel (la façon dont sont appelées les fonctions, en particulier comment sont passés les paramètres) pour l'architecture ARM. Le patch m'a demandé beaucoup de temps : il m'a fallu d'abord comprendre le problème, ensuite apprendre la nouvelle convention d'appel, me familiariser avec le code gérant l'ancienne convention d'appel puis enfin effectuer l'implémentation et déboguer le tout. Une fois le patch fini je me suis alors rendu compte qu'il fallait également ajouter le support de nouvelles relocations (une relocation est un processus consistant à calculer l'adresse finale d'une fonction ou d'une variable et à mettre à jour tous les endroits dans le code référençant ces éléments).

J'ai également trié les rapports de bogues sur Savannah (le service GNU qui héberge le site de TinyCC) et ai globalement été prompt à répondre aux rapports de bogues tant dans Debian que sur la liste de diffusion. J'ai aussi cassé TinyCC de nombreuses fois mais ai toujours été là pour réparer et au final personne ne m'a fait de reproches.

Au travers de tous ces petits patches et de la plus grosse série que constitue le support de la nouvelle convention d'appel, j'ai donc fini par me faire remarquer de la personne ayant été responsable des deux dernières publications de TinyCC : Grischka. Par exemple, après avoir demandé plusieurs fois de mettre à jour la branche principale par rapport à la branche de développement (lorsque celle-ci était stable), cette personne a fini par me donner les droits de commit sur celle-ci. De la même façon, à force de suggérer qu'on devrait enfin faire une nouvelle publication, cette personne m'a suggéré que je devrais la faire.

La publication a pris plus longtemps que je ne le pensais et en particulier m'a demandé plus d'efforts que je ne le pensais. En effet, je voulais être sûr que tout fonctionne correctement, aussi ai-je fait un appel à tests. J'ai été agréablement surpris, mais aussi un peu débordé, de voir autant de réponses. Ces réponses m'ont permis de découvrir de nombreux bogues que je ne soupçonnais pas et nous a permis de les corriger. Bien que cela ait pris du temps, le résultat est pour moi beaucoup plus satisfaisant car je sais que la qualité est meilleure ainsi. Je recommencerai donc avec plaisir la prochaine fois en essayant de laisser moins de temps s'écouler d'ici là. J'aimerais qu'on fasse une publication par an environ, voire tous les un an et demi. Le faire plus souvent serait inutile car le développement n'est pas très rapide pour l'instant.

DLFP : Peux-tu expliquer comment se déroule un cycle de publication de TinyCC ?

Je ne peux pas répondre pour les cycles précédents car je ne suivais pas le développement de près. En ce qui concerne ce cycle, il n'y a pas eu de processus bien défini pour la simple raison que ce n'est à mon avis pas nécessaire pour le moment : la participation est encore faible et il n'y a que très peu de contributeurs réguliers. Si la participation augmente, un processus se mettra en place. Pour l'instant, les gens contribuent lorsqu'ils en ont l'envie et le temps et la publication se fait quand quelqu'un le décide. De plus, je n'ai su qu'assez tard que ce serait moi qui ferais la publication, environ 2-3 mois avant la publication elle-même.

Cependant, dès qu'il m'a été suggéré de m'en occuper, j'ai annoncé mon intention de faire une nouvelle publication et ai fait un appel à tests. J'ai alors pris le temps de lire chaque rapport de bogue et ai essayé d'en corriger le plus possible. Grischka, qui a effectué les deux publications précédentes, a été d'une aide très importante en me suggérant des commits à défaire car (i) effectuant de trop grosses modifications, (ii) encore un peu instables ou (iii) non souhaitables dans TinyCC (typiquement les fonctionnalités ajoutant le support de l'optimisation à TinyCC, qui le rendent plus lent à compiler). Daniel Glöckner a également participé en corrigeant plusieurs bogues concernant l'architecture ARM avant que je n'aie eu le temps d'y regarder de plus près.

Est venu enfin le temps de la publication à proprement parler. Pour que celle-ci se fasse un choix a dû être fait concernant la présence de bogues connus. En effet, quelques jours avant de publier la nouvelle version il a été découvert que TinyCC ne parvient pas à compiler des projets faisant usage de fonctions variadiques (fonctions ayant un nombre variables d'arguments) lorsque la bibliothèque de gcc (libgcc_s) est utilisée. Devant l'incertitude concernant le temps nécessaire pour régler ce problème, il a donc été décidé de procéder à la publication en l'état. Cette nouvelle version apporte tout de même de nombreuses nouveautés et corrige beaucoup de bogues.

DLFP : Y a-t-il déjà des plans quant aux fonctionnalités prévues pour la prochaine version de TinyCC ? Et à plus long terme ?

Il n'y a pas de plan au niveau du projet dans le sens où on se mettrait d'accord sur une liste de fonctionnalités à ajouter. Les ajouts se font en fonction des motivations de chacun, de façon non coordonnée. Étant donné le faible nombre de contributeurs réguliers, il me semble à la fois trop ambitieux et inutile de décider d'une feuille de route pour TinyCC. De plus, il me semble que même parmi les contributeurs réguliers il n'y a pas d'idée précise de la direction vers laquelle nous souhaitons faire évoluer TinyCC.

En revanche, j'ai une liste personnelle de changements que j'aimerais voir dans TinyCC. Cette liste est trop longue pour que tout soit réalisé en un an sur mon temps libre aussi seule une partie de ces changements verra le jour dans la prochaine version. Le reste sera donc reporté aux versions suivantes. Par contre je ne peux encore vous dire quels changements seront effectués en premier. Voici la liste :

Correction de bogues

  • synchronisation des caches de données et d'instructions avant d'exécuter un programme compilé (fait)
  • création de la bibliothèque libtcc1.a pour l'architecture ARM avec :
    • les divisions entières (idiv, idivmod, uidiv, uidivmod)
    • la fonction __clear_caches nécessaire pour assurer la synchronisation entre les caches d'instructions et de données
    • les opérations en virgule flottante (nécessaires pour la convention d'appel ARM EABI)
    • les autres fonctions requises pour la convention d'appel ARM ABI
  • permettre à tous les tests de passer sur kFreeBSD et Hurd
  • corriger l'édition de lien pour que objdump et gdb acceptent de lire les exécutables produits sans l'option -g
  • ajout de la génération de code PIC (indépendant de la position finale)
  • réécriture plus propre de la convention d'appel ARM hardfloat
  • détecter lorsqu'une fonction est déclarée statique mais définie non statique (et vice versa)
  • rendre les accolades optionnelles dans les structures imbriquées comme requis par le standard C99
  • prise en compte du code de retour de parse_btype dans la fonction struct_decl
  • corriger certains des bogues déclarés sur Savannah

Ajout de fonctionnalités

  • choix de la convention d'appel à l'exécution pour les architectures ARM 32 bits
  • support de l'architecture ARM 64 (aussi connue sous le nom de ARMv8 ou aarch64)

DLFP : Y a-t-il quelque chose que tu voudrais ajouter ?

Je souhaiterais remercier encore une fois l'ensemble des personnes ayant contribué à la réalisation de cette nouvelle version de TinyCC. Je souhaite en particulier remercier Grischka qui a travaillé au moins autant que moi sur cette nouvelle version. Son expertise sur le code est plus grande que la mienne et ses remarques et patches ont été déterminants pour sortir cette nouvelle version.

J'invite aussi les lecteurs de LinuxFr.org qui s'intéressent aux compilateurs à jeter un œil à TinyCC. Comparé à LLVM/clang ou GCC, TinyCC est très petit et donc plus facile à appréhender. De plus, il est très facile d'y contribuer et il reste de nombreuses contributions simples à faire. Je ne connaissais rien à la compilation lorsque j'ai commencé à étudier TinyCC et j'ai appris énormément depuis.

DLFP : Merci beaucoup, Thomas, d'avoir pris le temps de répondre à ces questions (et de m'avoir aidé à traduire la liste des changements !).

  • # Pas de support C++

    Posté par . Évalué à  6 .

    Et contrairement à ce que laisse penser la présentation de la news, il n'y a pas de support C++. La question avait été abordée à une certaine époque il me semble sur la mailing list, mais, vu la complexité, ça n'a semble-t-il débouché nulle part.

    C'est bien dommage, car du fait de la lenteur de gcc dans ce domaine, avoir un compilo super rapide serait extrêmement pratique lors du cycle de développement, quitte à compiler les releases avec un compilateur plus conventionnel capable de mieux optimiser le code.

    Enfin, je critique, mais ça reste un projet très sympathique ! Longue vie à TinyCC !

    • [^] # Re: Pas de support C++

      Posté par . Évalué à  5 .

      C/C++ correspond à la catégorie de la dépêche. En effet, TinyCC ne supporte pas C++ bien que des gens aient proposé de supporter au moins un sous-ensemble de la syntaxe C++ qui permet de compiler les projets de petite à moyenne taille n'utilisant pas toutes les constructions du C++. Il a été considéré que cela nécessiterait l'ajout de beaucoup de code et ralentirait donc la vitesse de compilation. Il a donc été décidé de ne pas intégrer le support de C++ dans TinyCC. Il reste possible cependant de faire un fork de TinyCC supportant le C++ et nous pouvons alors ajouter un lien vers ce fork pour les gens qui seraient intéressés.

      • [^] # Re: Pas de support C++

        Posté par . Évalué à  3 .

        La vitesse de compilation reste toujours une priorité du projet ?

        Est-ce que le projet peut être aussi vu comme un moyen d'étendre une autre application comme lua ?

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: Pas de support C++

          Posté par . Évalué à  7 .

          Oui, je dirai que la vitesse de compilation est la priorité principale du projet. Pas dans le sens où tous les changements visent à améliorer cette vitesse — c'est plutôt rare en fait — mais dans le sens où c'est un des objectifs principaux du projet et donc un critère de décision important pour l'acceptation d'un changement. Cela dit, il n'est arrivé qu'une fois ou deux qu'un changement soit accepté car considéré trop lourd. TinyCC a plusieurs fonctionnalité mais c'est à mon avis sa rapidité et sa taille qui lui sont vraiment unique. On peut trouver les autres fonctionnalités ici ou là dans d'autres compilateurs. Il y a peut-être aussi le test de dépassement de bornes (bound checking) qui est assez atypique mais pas unique je pense.

          Corcernant l'utilisation de TinyCC comme un moyen d'étendre une application je ne suis pas sûr exactement de comprendre la question mais je pense que la réponse est oui. Le projet TinyCC fournit une bibliothèque statique (libtcc.a) qui peut être incorporée dans un programme pour compiler du C à l'exécution. Il est donc tout à fait faisable de faire un compilateur à la volée (JIT) avec TinyCC et il me semble même que cela a été fait.

          • [^] # Re: Pas de support C++

            Posté par . Évalué à  -6 .

            Cela dit, il n'est arrivé qu'une fois ou deux qu'un changement soit accepté car considéré trop lourd.

            Ça compile pas /o\
            « Cela dit, il n'est arrivé qu'une fois ou deux qu'un changement soit refusé car considéré trop lourd ».
            Yeah !

            SamWang, débugger de langage naturel [contrôlé].

    • [^] # Re: Pas de support C++

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

      C'est bien dommage, car du fait de la lenteur de gcc dans ce domaine, avoir un compilo super rapide serait extrêmement pratique

      Il y a mille raisons pour lesquelles compiler le C++ est lent, beaucoup plus lent que C. Une raison sont les templates, une autre, la dépendance au contexte du code.

      http://yosefk.com/c++fqa/picture.html#fqa-6.4

      • [^] # Re: Pas de support C++

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

        Le C aussi est dépendent du contexte.

        foo * bar; /* Si foo est un typedef, ça déclare un pointeur,
                          sinon c'est une multiplication. */
        a = (t)-1; /* Si t est un typedef, alors c'est un cast,
                          sinon c'est une soustraction. */
        
        

        Le C++ est peut être pire dans l'interpretation de < et > comme séparateur de template ou opérateur.
        Mais je ne pense pas que c'est ce qui ralentis le parsing.

        Je dirais plutôt que c'est le fait qu'il y ait tellement de headers, et qu'il doivent être re-parsé pour chaque translation unit

        • [^] # Re: Pas de support C++

          Posté par . Évalué à  4 .

          Ce qui est lent en C++, c'est pas l'analyse syntaxique ou la preprocession, c'est toutes les couches de métaprogramations entre les templates et les expressions constantes.

          À partir du moment ou tu cherche à avoir un tableau de taille "20ième nombre de la suite de fibonacci", tes temps de compiles explosent, même si ton source préprocéssé fait dix lignes.

          Et si on retire ces fonctionnalités là à C++, alors le langage n'a plus beaucoup d'intérêt.

          • [^] # Re: Pas de support C++

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

            Mais calculer les nombre de fibonacci est assez rare.
            Peu de C++ courant fait un usage intensif des template. Et pourtant la compilation est quand même lente. C'est parce que dés que on inclus les header standard, ça inclus plein de headers qui contienne pas mal de templates.

            C'est pour ça que les header pré-compilé rendent la compilation du C++ tellement plus rapide. Mais c'est un hack.

            • [^] # Re: Pas de support C++

              Posté par . Évalué à  -10 .

              Mais c'est un hack.

              Oh… toi ! Je te crois capable de comprendre The node !

            • [^] # Re: Pas de support C++

              Posté par . Évalué à  4 . Dernière modification : le 20/03/13 à 12:24

              Peu de C++ courant fait un usage intensif des template.

              Ça dépend de ce que tu appelle courant. Pour moi, une utilisation courante est le calcul numérique, et des fois il y a besoin d'algèbre linéaire, et des trucs comme armadillo ou itpp en font un usage non négligeable.

            • [^] # Re: Pas de support C++

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

              Peu de C++ courant fait un usage intensif des template.

              Dans STL¹ let T est pourtant pour template… Il n'y a pas de métaprogramme calculant la suite de Fibonacci dans la STL — pas que je sache, du moins :-) — mais comme le C++ est un langage relou où il n'y pas moins de 6 façons² de passer un argument à une fonction ou de récupérer son résultat et bien il y a tout un système de templates dans la STL qui sert à dire quoi utiliser quand dans quelles circonstances… C'est tellement important que chaque grosse bibliothèque fournit sa propre version — Boost et libG++ par exemple — pour être portable et stable bien comme il faut. Ce type d'information est notamment utilisé dans les systèmes de slots (l'équivalent d'une fermeture en C++ mais ici aussi il y a plus de 6 sortes de fonctions différentes!).

              Je ne suis pas spécialiste du langage, mais je pense qu'à chaque fois qu'un template est instantié, l'analyse syntaxique (sinon le mot-clef typename ne servirait à rien) est refaite. De plus les templates sont instantiés beaucoup plus souvent qu'on ne le croit à cause de la surcharge des opérateurs.

              La surcharge des opérateurs couplée aux conversions automatiques sont probablement aussi une pénalité pour la vitesse de compilation. Si j'ai 800 classes qui définissent une srucharge de l'opérateur << (pas le décalage de bits mais le stream output) et bien à chaque fois que j'écris s << a pour une classe a qui ne définit pas de surcharge de l'opérateur << et bien le compilateur va essayer de convertir automatiquement a dans l'une des 800 classes en question…

              ¹ La bibliothèque standard du C++ pour les profanes.
              ² Par copie ou par valeur immédiate (ce qui fait une façon), par référence, par référence constante, par pointeur, par pointeur constant, par pointeur void (cas «détypé»).

              • [^] # Re: Pas de support C++

                Posté par . Évalué à  5 . Dernière modification : le 20/03/13 à 23:54

                Tu à oublié le passage par déplacement ;)

                Pour les surcharge d'opérateurs, c'est plus simple que ça. Le compilateur ne va chercher des surcharges membres dans s ou dans le namespace du type de s ou de a. Et si les conversions foires ou qu'il n'y en a pas une seule surcharge définie, ça ne va pas plus loin.

                Donc non, si tu définit tes 600 surcharges d'opérateurs correctement et que tu reparti tes types maisons dans des espace de noms différents, ton compilo ne va pas essayer 600 conversions.

                Mais bon, les lenteurs de compilations de C++ ne sont pas si grandes que ça lorsqu'on utilise pas un métaprogramme qui génère des analyseurs syntaxiques ou des expressions rationnelles.

  • # Merci

    Posté par . Évalué à  7 .

    Merci pour cette dépêche. Il m'est déjà arrivé de me servir de tcc, mais je n'en suivais pas le développement (je l'imaginais plus ou moins à l'abandon).

    Merci de me faire découvrir que tcc, n'est pas mort bien au contraire.

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Merci

      Posté par . Évalué à  4 .

      J'ai utilisé ce compilateur par hasard mais je pense qu'il est très intéressant de part sa rapidité de compilation et génération de code simplifiée.
      Cette dépêche est très sympathique.

  • # Bug ?

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

    En voulant faire une petite installation locale de tcc, je m'aperçois que le script configure a un comportement étrange:

    Contrairement aux autres variables, le chemin donné par la variable --tccdir n'est jamais absolu, mais toujours $LIBDIR/$TCCDIR sur unix/linux, est vaut $PREFIX/$TCCDIR sous win32. Cf configure ligne 189 à 237.

    Il me semble que si on utilise la variable --tccdir lors de la configuration, on s'attend à ce qu'elle soit considérée comme telle.

    • [^] # Re: Bug ?

      Posté par . Évalué à  1 .

      Bien vu, mais il vaut mieux envoyer un rapport de bogue aux mainteneurs que de le signaler ici.
      Je ne crois pas qu'ils moulent sur linuxfr.

      • [^] # Re: Bug ?

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

        Manifestement, tu as raison, pourtant, il était écrit que le mainteneur du moment est « connu sur LinuxFR sous le pseudonyme robotux ».

    • [^] # Re: Bug ?

      Posté par . Évalué à  1 .

      Désolé de n'avoir pas répondu plus tôt. J'ai bien vu ton message et je vais voir pour changer le nom de l'option en --tccreldir. Merci pour l'information :)

      • [^] # Re: Bug ?

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

        De rien.

        J'ai essayé d'envoyer un message sur la liste de discussion, mais il a été refusé par le robot faute d'être inscrit, et je n'ai pas pris le temps de m'inscrire…

Suivre le flux des commentaires

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