GCC 3.3 est sorti

Posté par  . Modéré par Amaury.
Étiquettes :
0
16
mai
2003
GNU
Le projet GNU vient de sortir une nouvelle version de sa suite de compilation (GCC, Gnu Compiler Collection), qui prend en compte les langages suivants: C, C++, Objective-C, Fortran, Java, et Ada.

Au menu de cette version, on notera de nombreuses corrections de bugs, un nettoyage du code, l'ajout de nouvelles optimisations (en particulier, l'utilisation du "DFA scheduler" ainsi que le support de SSE2 et 3dNOW! pour les architectures ia32).

Pour ce qui concerne spécifiquement le langage C, on notera un léger rapprochement du standard C99. L'interpréteur java intègre directement les threads et est donc plus rapide. La gestion des tâches ADA utilise maintenant les bibliothèques de threads de la glibc 2.3.

Aller plus loin

  • # Modéros HS?

    Posté par  . Évalué à 2.

    Faudrais suivre un peu les modérateurs, y a déjà une news sur gcc 3.3 dans la boîte autre. Notez que je trouve que ça a sa place en première page, mais alors qu'on supprime la news dans autre.

  • # Compatibilité?

    Posté par  . Évalué à 7.

    Et la question à deux centimes d'euros: Le code C++ compilé par g++ 3.3 est-il compatible avec celui de g++ 3.2, ou bien comme pour les trois versions précédentes faut encore tout recompiler?

    • [^] # Re: Compatibilité?

      Posté par  . Évalué à 6.

      D'après le Changelog (de mémoire), l'ABI est conservée sur certaines archis, l'exception notoire risquant d'embéter le plus de monde étant les i386-* (qu'il s'agisse de vrai 386 ou de machines plus récentes mais visant la compatibilité). Cela dit, de nos jours, on est tous en i586 ou i686, hein? :)

      • [^] # Re: Compatibilité?

        Posté par  (site web personnel) . Évalué à 10.

        Je crois que les dev de gcc veulent rapprocher l'ABI de celle du compilo windows, histoire de pouvoir lier des modules compilés avec gcc sous windows avec des modules compilés avec le compile MS. C'est pas une mauvaise idée... Si sun pouvait faire la même chose sur solaris, ça nous faciliterait la vie de tous les jours (et m..., je peux pas compiler ce truc avec gcc parcequ'on se lie dynamiquement avec la libc++ compilée avec CC) Le tout est que tout ce beau monde se mette d'accord pour avoir un mandling commun ....

        • [^] # Re: Compatibilité?

          Posté par  . Évalué à 3.

          Tu veux pas dire plutôt mangling ?

          • [^] # Re: Compatibilité?

            Posté par  (site web personnel) . Évalué à 5.

            sûrement ... suis pas sûr de moi.
            En tout cas, la façon dont sont représentés les différents symboles du programme :
            si tu fais nm sur un .o dont le source est du C++, tu vas voir des trucs du style
            Zxffr00wMaClassekjqsmaMéthodefhstringslmjintsldkfj

            En C, le nom de la fonction seul suffit, mais en C++ non : il faut rajouter les types des paramètres pour la surcharge, l'info sur la classe, les namespace, etc .

            Et bien sûr, rien tout ça n'est spécifié dans la norme ... alors chacun fait comme il veut

        • [^] # Re: Compatibilité?

          Posté par  . Évalué à 1.

          Je crois que les dev de gcc veulent rapprocher l'ABI de celle du compilo windows

          je ne suis pas dévellopeur (un peu de C/C++ quand c'est nécessaire mais rien de sophistiqué) encore moins spécialiste sur les compilateurs mais je suis un peu surpris que l'ABI C++ du compilateur libre GNU soit modifié seulement dans le but de coller à celle de Microsoft. Quelqu'un pour confirmer/infirmer?

          • [^] # Re: Compatibilité?

            Posté par  . Évalué à 6.

            Pour la version 3, leur but c'était de coller à une ABI standard pour éviter le genre de pb qu'il y a eu entre gcc 2.95/2.96 et 3
            Entre la version 3.0 et la 3.1, ils ont été obligé de modfiier un peu l'ABI pour corriger des bugs, entre la 3.1 et la 3.2 il y a eu qques changements mineures encore une fois à cause de bugs, je sais pas trop les changements introduits à l'ABI dans la version 3.3
            A mon avis, microsoft utilise aussi cette ABI standard pour son compilateur, et tout ce que font les devels de gcc, c'est corrigé au fur et à mesure les bugs dans gcc pour se conformer à cette ABI standard.

          • [^] # Re: Compatibilité?

            Posté par  . Évalué à 3.

            Si j'ai bien compris la remarque précédente, ça ne concerne que Windows, non ?

            Sinon, pour les principales évolutions de l'ABI au passage à gcc 3.x, c'est pour des vraies raisons de fond, l'ancienne ABI devenait vraiment archaïque, et une fois la nouvelle définitivement stabilisée, celle-ci devrait tenir 10 ou 15 ans, sans qu'il y ait de besoin de la changer (de manière incompatible)
            Et tout ça ne concerne que le C++, pas le C.

            • [^] # Re: Compatibilité?

              Posté par  (site web personnel) . Évalué à 4.

              Si j'ai bien compris la remarque précédente, ça ne concerne que Windows, non ?

              Je ne pense pas, ça serait quand même dommage de changer le format des objets suivant la plateforme :
              *Au niveau de la maintenance, si tu as n plateformes, ça multiplie par autant les bugs, et ça, c'est très mal. [De façon générale, en dev multiplateforme, le moins de code spécifique tu as, le mieux tu te portes]
              *Sans parler du prix de l'ajout d'une nouvelle plateforme

              Brefle, utilisons tous le même format sur toutes les plateformes, et on sera tous heureux (vrai aussi pour les formats de fichiers office ou les normes W3C ... )

              • [^] # Re: Compatibilité?

                Posté par  . Évalué à 3.

                Donc comme le dit simplement Master-dik les modifications apportées le sont pour se conformer à ce qui doit être considérer comme le standart des ABI. Si tous le monde fait de même alors logiquement que ce soit GNU, Sun ou Microsoft, ils devraient tous parvenir au même résultat.

              • [^] # Re: Compatibilité?

                Posté par  (site web personnel) . Évalué à -3.

                De façon générale, en dev multiplateforme, le moins de code spécifique tu as, le mieux tu te portes

                ce serait pas plutôt "le moins de code spécifique, le moins tu portes"?

                (sans commentaire)---->[]

        • [^] # Re: Compatibilité?

          Posté par  . Évalué à 3.

          Je crois que les dev de gcc veulent rapprocher l'ABI de celle du compilo windows

          Non, ils veulent se rapprocher de l'ABI C++ standard. C'est pas pour faire plaisir à Bill Gates.

          • [^] # Re: Compatibilité?

            Posté par  . Évalué à 1.

            « Non, ils veulent se rapprocher de l'ABI C++ standard. »

            Quel standard, tu as des précisions ?

            • [^] # Re: Compatibilité?

              Posté par  . Évalué à 4.

              C++ est standardisé par l'ISO,
              mais le standard ne semble pas disponible
              en téléchargement libre et gratuit.
              Voir :
              http://www.comeaucomputing.com/iso/(...)
              où ils disent que tu dois donner 18 dollars pour le télécharger.

              Tu peux par contre récupérer le standard C99 (plutot un
              draft ; après je ne sais pas s'il y a beaucoup de différences
              entre le draft et le document final), disponible par exemple à :
              http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf(...)

              http://gcc.gnu.org/readings.html(...)
              est un point de départ possible pour te renseigner un peu
              plus sur ces choses.

              C'est dommage qu'il faille payer pour lire les standards...
              Lire à ce propos une petite remarque de la FAQ libstdc++
              http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_7(...)
              où il est dit :
              "[...] or those who have not paid for the privilege of sitting on the committee and sustained their two-meeting commitment for voting rights, may get a copy [...]"
              qui dit bien ce qu'elle dit.

              • [^] # Re: Compatibilité?

                Posté par  . Évalué à 1.

                la citation complète (j'ai du mal avec le sens exact) :

                "5.7 How do I get a copy of the ISO C++ Standard?

                Copies of the full ISO 14882 standard are available on line via the ISO mirror site for committee members. Non-members, or those who have not paid for the privilege of sitting on the committee and sustained their two-meeting commitment for voting rights, may get a copy of the standard from their respective national standards organization. In the USA, this national standards organization is ANSI and their website is right here. (And if you've already registered with them, clicking this link will take you to directly to the place where you can buy the standard on-line.

                Who is your country's member body? Visit the ISO homepage and find out!"

                mais l'ironie est bien présente, non ?

              • [^] # Re: Compatibilité?

                Posté par  . Évalué à 1.

                « C++ est standardisé par l'ISO, » [snip]

                Oui, mais ce n'était pas du tout ma question, tout ça je connais :)

                Master-dik parle d'ABI C++ standard. C'est ça qui m'intéresse. Est-ce un projet, une proposition de standardisation ? La norme ISO C++ actuelle ne parle pas d'ABI, ou laisse suffisamment de libertés aux concepteurs de compilateurs. Je sais que ce choix a été fait pour de « bonnes raisons », c'est-à-dire qu'ils se sont vraiment posés la question, et n'ont pas voulu standardiser l'ABI. Ma question porte donc sur un éventuel standard d'ABI C++. Est-ce que finalement il y a un effort de standardisation là-dessus ?

      • [^] # Re: Compatibilité?

        Posté par  . Évalué à 4.

        Cela dit, de nos jours, on est tous en i586 ou i686, hein? :) non pas debian mais il y en a qui en parlent

    • [^] # Re: Compatibilité?

      Posté par  . Évalué à 3.

      Par défaut, oui.

  • # Re: gcc 3.3 est sorti

    Posté par  (site web personnel) . Évalué à 5.

    > [...] qui prend en compte les langages suivants: C, C++, Objective-C, Fortran, Java, et Ada. ...et VHDL ?

  • # Interpréteur Java

    Posté par  . Évalué à 10.

    La traduction française de la news est foireuse. "The bytecode interpreter is now direct threaded and thus faster" new veut pas du tout dire "L'interpréteur java intègre directement les threads et est donc plus rapide." Direct threaded code est une technique de simulation de code visant à stocker des pointeurs directement vers le label débutant un handler d'opcode. Par exemple: #include <stdio.h> #define DISPATCH_NEXT(ip) goto **ip++ int main(void) { void *prog[] = { &&add, &&sub, &&stop }; void **ip = prog; DISPATCH_NEXT(ip); add: printf("add\n"); DISPATCH_NEXT(ip); sub: printf("sub\n"); DISPATCH_NEXT(ip); stop: printf("stop\n"); return 0; } C'est une vieille technique, c.f. un article de Bell73 par exemple. De nos jours, la variante est améliorée en copiant carrément le code. Voir notament "Improving direct threaded code with selective inlining" de Ian Piumarta, 1998 (titre de mémoire, approximatif). Plus récemment, voir qemu de Fabrice Bellard.

  • # Re: gcc 3.3 est sorti

    Posté par  . Évalué à 3.

    le support de SSE2 et 3dNOW! pour les architectures ia32 Est-ce que quelqu'un peut dire comment ça se traduit dans la pratique? Ce sont les "targets builtins"? (voir la page info de gcc 3.2, chapitre "C extensions"). Ou est-ce seulement la reconnaissance des opérandes assembleur? Autre question qui découle de ça: les builtins mmx par exemple sont-ils simples à s'en servir ou vaut-il mieux des bouts de code asm à la place?

    • [^] # Re: gcc 3.3 est sorti

      Posté par  (site web personnel) . Évalué à 2.

      Il y a des instructions scalair en SSE2 qui permet d'éviter la pile x87 très mal gérer par Gcc. Coté codage, je viserais le built-in, car la distribution des registres est faite par gcc, ce qui est un poid en moins.

      "La première sécurité est la liberté"

    • [^] # Re: gcc 3.3 est sorti

      Posté par  . Évalué à 1.

      Pour moi, il reconnait juste les operandes. Enfin, c'est comme ca que je comprends la phrase "SSE2 and 3dNOW! intrinsics are now supported."

      • [^] # Re: gcc 3.3 est sorti

        Posté par  . Évalué à 2.

        Les "intrinsics", ce sont normalement des fonctions qui se transforment en assembleur inline lorsque l'architecture cible le permet. Par exemple si la FPU visée est capable de calculer le sinus en hard, la fonction fsin() sera remplacée par l'utilisation du mnémonique adéquat.

  • # Re: gcc 3.3 est sorti

    Posté par  (site web personnel) . Évalué à 7.

    Et pour les ceusses qui aiment le sport, la version 3.4 est sur le grill, et la premiere fonctionnalité qui a été ajouté est la précompilation des headers. ca va compiler plus vite, chérie!

    • [^] # Re: gcc 3.3 est sorti

      Posté par  . Évalué à 1.

      précompilation des headers Ça c'est une bonne nouvelle... y'a des projets (au hasard, KDE) qui vont bien profiter de ce genre de fonctionnalité.

      • [^] # Re: gcc 3.3 est sorti

        Posté par  (site web personnel) . Évalué à 7.

        KDE a déjà sa propre "solution", qui est de concatener tous les fichiers d'un répertoire en un seul gros fichier, qui est compilé en une fois quand on fait "make final". http://developer.kde.org/documentation/other/developer-faq.html#q58

      • [^] # Re: gcc 3.3 est sorti

        Posté par  (site web personnel) . Évalué à 2.

        Petit bémole, la précompilation ne peut marcher que sur le premier fichier inclu. Sinon, vu que les définitions de macros des fichiers précédament inclus peuvent changer la facon de compiler, ça n'a aucun sens. Par contre #include "mon_fichier_point_h_qui_inclue_tous_les_autres.h" marche, bien sur.

        • [^] # Re: gcc 3.3 est sorti

          Posté par  (site web personnel) . Évalué à 4.

          Bein ca depend de la tete du fichier precompile. Borland C++ etait terrible pour ca, il te precompilait tout tes headers de ton projet dans un seul gros fichier (15Meg l'epoque ct gros :)) mais apres tant que tu changait pas tes .h ca roxait bien :)

        • [^] # Re: gcc 3.3 est sorti

          Posté par  . Évalué à 4.

          "Précompiler" les headers ne veut certainement pas dire générer du code, mais sauvegarder une représentation intermédiaire, parsée et analysée, pour que ça aille plus vite par la suite. Dans cette optique les références aux symboles non résolus peuvent être laissées telles quelles. Quant aux macros les indications laissées en commentaires par le précompilateur doivent permettre de bidouiller un système de dépendances entre headers, j'imagine.

          Un gros bémol est que ça produit, a priori, des fichiers énormes (en tout cas sous Visual Studio c'est le cas : plusieurs Mo de headers précompilés si tu inclus le windows.h ou la STL).

          • [^] # Re: gcc 3.3 est sorti

            Posté par  . Évalué à 1.

            je crois que ca n'est seulement utile que pour les templates. Sur SUN il y a une option semblable aussi.

          • [^] # Re: gcc 3.3 est sorti

            Posté par  (site web personnel) . Évalué à 2.

            Pour l'instant, il semble que l'approche tout dans un fichier soit retenue par GCC.

            http://gcc.gnu.org/ml/gcc/2003-01/msg01008.html(...)

            Dans les autres cas, je ne vois pas trop comment le compilo peut faire pour générer un truc indépendant des macros définies avant. On peut faire un truc qui marche dans beaucoup de cas, mais si le programmeur a vraiment fait des trucs crades avec ses "#define" (Par exemple, dans le source de GCC, il y a des fichiers inclus plusieurs fois dans un contexte différent et qui ne font pas *du tout* la même chose -- Genre la première fois ça défini un type énuméré, et la suivante, ça défini une grammaire d'arbre sur ce type ...), la seule solution est de suivre l'approche tout dans un fichier, mais en générant toutes les combinaisons d'include possibles ...

            Par contre, là ou il n'y a pas trop de macros, typiquement la STL, on doit pouvoir faire des choses.

    • [^] # Re: gcc 3.3 est sorti

      Posté par  . Évalué à 1.

      Ya un lien quelque part qui indique ce qu'il va y avoir sur le 3.4 (c'est surtout pour connaître le statut de l'ObjC++) ?

  • # Questions trés techniques.

    Posté par  (site web personnel) . Évalué à 2.

    Quelqu'un a déjà utilisé l'option -fprofile-arcs ? Comment cela fonctionne exactement ? Dois-je compiler l'appli une première fois, l'installer puis l'utiliser intensivement (1 ou plusieurs fois ?). Et enfin recompiler l'appli ? Comment ça fonctionne pour une bibliothèque, dois-je bidouiller avec LD_LIBRARY_PATH et une appli l'utilisant pour générer des stats ? Les options -freorder-functions et -ftracer sont t'elles efficaces ?

    • [^] # Re: Questions trés techniques.

      Posté par  . Évalué à 3.

      de ce que j'ai fait avec le intel C++ :
      tu compile avec des flags kivonbien.
      tu fais tourner dans des condition s représentatives de la réalité.
      tu recompile avec les autres flags kivonbien.

      je gagnais 25% sur une scène POV (une seule, c'était pour voir un peu) à l'époque.

      • [^] # Re: Questions trés techniques.

        Posté par  . Évalué à 2.

        c'est surtout utile si tu as beaucoups de branchement dans ton code. ca peut aider aussi pour mieux placer les prefetchs dans certaines boucle, si il n'y a pas d'aliasing de pointeur.

  • # Re: gcc 3.3 est sorti

    Posté par  . Évalué à 0.

    pas vraiment à voir, mais est-ce que qu'lqu'un utilise Objective-C ici? Si oui que peut il me dire de ce langage par rapport a C ou C++

    • [^] # Re: gcc 3.3 est sorti

      Posté par  . Évalué à 4.

      il est introspectif par nature, permet de gerer assez facilement la serialisation (car il gere une sorte de versionning).

      Au final c le deuxieme langage objet ayant des origines C mais qui lui a garder le plus de racines avec son "ancetre" tout en evitant certaines des grosses failles de son petit frere. (qui lui reste malgre tout ses defauts le plus puissant)

      • [^] # Re: gcc 3.3 est sorti

        Posté par  . Évalué à 4.

        D'après ce que j'en ai vu l'intérêt de l'Objective-C est surtout lié à la qualité des frameworks qui vont avec (que ce soient ceux d'Apple ou ceux de GNUstep).
        Linux Magazine y a récemment consacré quelques articles (n°47 Introduction au projet GNUstep et n°49 Vos premiers pas en programmation sous GNUstep). Si tu veux réellement voir en quoi l'Objective-C est bien alors je te conseille de faire le tutorial du n°49.

        Je ne me risquerai pas à le comparer avec d'autres langages vu mon expérience trés réduite en programmation et mon parti pris pour l'Objective-C vu que j'utilise Mac OS X (oui je sais c'est mal :-).

        Quelques liens :
        http://www.gnustep.org(...) (site officiel)
        http://www.gnustep.it(...) (tutoriaux et exemples)

      • [^] # Re: gcc 3.3 est sorti

        Posté par  (site web personnel) . Évalué à 2.

        Une super description/tutorial (en anlgais)
        http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/3objc_l(...)

        Sinon, j'aurais moi aussi une requête: je me suis décidé récement à me lancer dans l'apprentissage d'un langage (marre d'être inutile), et après quatres jours à choisir lequel, celui-ci m'avait bien plu.
        Seulement, je trouve GNUstep... pas très attirant (sans l'avoir testé). Et comme les bindings KDE sont cassés, j'ai laissé tomber et me suis mis au C++.

        Alors si quelqu'un connaissait un autre environement (je suis pas sûr que ce sois le bon terme), pour programmer en ObjC et acceptait de donner une url, je lui en serais reconaissant (ça me permettrais de revenir à ce merveilleux langage ^_^)

        (sinon, faites gaffe aux trolls, parler des langages OO c'est dangereux)

        • [^] # Re: gcc 3.3 est sorti

          Posté par  (site web personnel) . Évalué à 2.

          Non, tu peux programmer directement en Objective-C, mais le seul framework existant est GNUstep (ou Cocoa bien sûr). Sinon il te reste les bindings KDE ou GNOME, mais je ne sais fichtre pas dans quel état ils sont. Par curiosité, qu'est-ce qui ne t'as pas attiré dans GNUstep ?

          • [^] # Re: gcc 3.3 est sorti

            Posté par  . Évalué à 1.

            Lui, je ne sais pas, mais en ce qui me concerne, le fait que GNUstep ne gère pas la mémoire comme le fait Cocoa m'a un peu déçu.

            L'utilisation d'autorelease pools entraîne systématiquement une segfault du soft :(

            J'ai hâte que GNUstep se rapproche encore un peu plus de Cocoa, peut-être jusqu'au point de n'avoir qu'à compiler avec l'un ou l'autre sans modifs du code (les NIBs, c'est une autre question).

            JB.

            • [^] # Re: gcc 3.3 est sorti

              Posté par  . Évalué à 1.

              >Lui, je ne sais pas, mais en ce qui me concerne, le fait que GNUstep ne gère pas la >mémoire comme le fait Cocoa m'a un peu déçu.
              >L'utilisation d'autorelease pools entraîne systématiquement une segfault du soft :(

              explicite ?
              J'ai porté 4/5 aplis et je n'ai pas rencontré le problème

              >J'ai hâte que GNUstep se rapproche encore un peu plus de Cocoa,
              La politique actuele est d'implémenter les extentions de Cocoa ( ce qui est fait dans la
              majorité des cas)
              Seul le extentions "pas saines" de Apple ne sont pas implémentés

              > peut-être jusqu'au point de n'avoir qu'à compiler avec l'un ou l'autre sans modifs >du code

              Il n'y a que très peu de modifs à faire si ce n'est que du Cocoa :
              - Le problème c'est que Apple enlève des Warnings à gcc :)
              - n'utilises pas CoreFoundation
              - n'utilises pas NSDrawer ( les dévelopeurs GNUstep n'en veulent pas )
              - n'utilises pas Cocoa/Cocoa.h comme hearders
              - n'utilises pas AppleScript et Quicktime.
              - attention #import va être supprimé à partir de gcc3.4

              Tu peux toujours venir sur #gnustep pour plus d'infos...

              Ton application est libre ?

              • [^] # Re: gcc 3.3 est sorti

                Posté par  . Évalué à 1.

                Il y a une explication au fait que les développeurs GNUstep ne veulent pas des NSDrawer ?
                Moi en tant qu'utilisateur je trouve ça plutot pas mal.

                Le fait de ne pas utiliser Cocoa/Cocoa.h rajoute un warning lors de la compilation, est-ce que ça ne risque pas de faire un joli bug plus tard (mon programme n'est pas fini donc je n'ai pas testé plus loin). A quoi sert en fait ce Cocoa/Cocoa.h ?

                Si le #import va être supprimé il va être remplacé par quoi ?

                Merci d'avance pour vos réponses.

          • [^] # Re: gcc 3.3 est sorti

            Posté par  . Évalué à 1.

            Fut un temps j'étais motivé pour me mettre à GNUStep. J'ai vu que Gentoo proposait des ebuilds tout chaud pour, "chouette" que je me suis dit. J'ai gentiment tout installé, et la misère: non seulement j'ai pas moyen de lui faire ajouter le bon PATH automatiquement (pas encore trop grave), mais quand j'invoque finalement "defaluts" pour configurer la bete, il me rale qu'il lui manque un libgnustep-base.so.1, alors que bien évidemment ca a été installé comme le reste.

            On verra plus tard, m'est avis :/

          • [^] # Re: gcc 3.3 est sorti

            Posté par  . Évalué à 1.

            En ce qui concerne les bindings KDE, ils sont normalement toujours à jour.

            En effet, les bindings KDE pour les autres langages sont générés automatiquement, donc il devraient toujours être au niveau de la dernière version de l'API KDE.

    • [^] # Re: gcc 3.3 est sorti

      Posté par  (site web personnel) . Évalué à 10.

      Oui on est quelques-uns à utiliser Objective-C ... :-)
      Objective-C, comme son nom l'indique, est un langage orienté objet basé sur C -- comme C++ .

      La différence réside dans l'approche; C++ n'est pas plus que ça orienté objet, c'est juste un des multiples paradigmes de programmation qu'il supporte.
      C++ a fait le choix de proposer un maximum de possibilitées dans le langage, mais en même temps essaie de ne pas pénaliser quelqu'un qui n'utiliserait qu'une partie de ces possibilitées (i.e., on ne paie que pour ce qu'on utilise).

      Accessoirement le modèle objet de C++ est plus inspiré de Simula que de Smalltalk, c'est à dire qu'il privilégie la compilation statique au runtime dynamique.

      Objective-C par contre a comme seul but de fournir des mécanismes de programmation orientée objet par dessus le langage C. Il n'ajoute ainsi que très peu de choses par rapport à C, mais ces choses sont fondamentales et permettent de changer complètement de paradigme et d'utiliser vraiment la programmation orientée objet. En cela il est différent de C++, qui ajoute énormément de choses. Personnellement, je trouve cette approche plus élégante car plus concise, mais ça dépends du but visé. Comme je l'ai dit, C++ n'a pas que la POO comme objectif.

      L'approche OO d'Objective-C est très inspiré par Smalltalk, et il dispose ainsi d'un runtime chargé de résoudre les envois de messages entre objets (ce qui du coup rends l'envoi de messages entre objets distants, sur des machines ou réseaux différents, absolument trivial). Objective-C est bien sûr compilé, mais ce runtime permets des choses particulièrement intéressantes, comme l'ajout pendant l'exécution de méthodes à des classes d'objets (dont on n'est même pas forcé d'avoir le source), voir la modification de la hièrarchie des objets. Le runtime permets également quelques possibilitées d'introspection, permettant de demander ainsi à un objet son type, s'il réponds à une méthode ou un protocole, etc. On peut aussi définir une méthode répondant à tout message envoyé (même si non défini), et éventuellement forwarder ces messages vers d'autres objets ...

      Bref, Objective-C a une nature dynamique, qui est particulièrement bienvenue quand on code -- au moins pour des logiciels avec interface graphique.

      Sinon, oui, un des principaux intérêts d'Objective-C est la disponibilité du framework OpenStep, dont l'implémentation sous Mac OS X (Cocoa) ou celle sous Unix/Windows/etc. (GNUstep) permettent de programmer de façon particulièrement élégante et efficace (enfin, c'est mon avis :).

      Bref selon moi, Objective-C est un langage élégant et souple, qui vaut le coup de s'y intéresser. Et OpenStep est le meilleur framework de programmation que je connaisse, point barre.

      Tu peux trouver des documentations sur GNUstep/Objective-C sur cette page : http://www.roard.com/docs/(...) , dont les articles parus jusqu'à présent dans Linux Mag. D'ailleurs le prochain article ne sera malheureusement pas pour Juin, mais pour Juillet :-/ (rendu trop tard ...)

      • [^] # Re: gcc 3.3 est sorti

        Posté par  . Évalué à 2.

        je mepermets d'écrire pour dire "je confirme tout cela"
        parce que Objective C et openstep forme vraiment un couple de qualité

        si vous vous lassez d'attendre que GNUSTEP soit parfait, foncez sur un mac et essayez cocoa

        sinon, par pitié, ne jugez pas gnustep a cause de son look (qui est pourtant sobre et efficace), il est celui du vénérable nextstep et a son epoque c t tres bien

        et ne jugez par rapport aux helas trop peu nombreuses applications gnustep, l'api, le langage est vraiment très cohérent et bien construit.

        Plus de gens y participeront, mieux se portera gnustep.

        • [^] # Re: gcc 3.3 est sorti

          Posté par  . Évalué à 1.

          > et ne jugez par rapport aux helas trop peu nombreuses applications gnustep

          Certes, mais ça reste un très très gros handicap pour attirer du monde. Le fait d'avoir un environnement cohérent (tout KDE ou tout Gnome, rien que pour les interactions entre logiciels) est un gros atout. Et force est de reconnaître que certaines applications «de base» manquent à GNUstep, comme par exemple un navigateur. Peut-être avec le support de l'ObjC++ dans gcc 3.4 (par contre, j'ai pas trouvé d'info au sujet de cette future intégration sur le site de gcc).

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Compiler avec gcc 2

      Posté par  . Évalué à 1.

      Il suffit de mettre la variable CC comme valant gcc
      dans ton makefile
      CC=/chemin/vers/gcc2

  • # Architecture Via C3

    Posté par  (site web personnel) . Évalué à 0.

    C'est un peu dommage mais il me semble que l'architecture VIA C3 n'est toujours pas correctement suportée (le VIA C3 n'a pas l'instruction CMOV optionnelle pour les i686). Il faut toujours compiler avec -m=i486

    • [^] # Re: Architecture Via C3

      Posté par  (site web personnel) . Évalué à 2.

      En fait, je viens de trouver l'option -mcpu=c3. Avec elle, plus d' "illegal instruction" et un code optimal.

      • [^] # Re: Architecture Via C3

        Posté par  (site web personnel) . Évalué à 2.

        Arg, cette option corespond aux vieux Cyrix (equivalent a un 486 avec mmx et 3dmox) et ne permet pas de tirer parti des VIA C3 (Erza) (equivalent 686 sans cmove avec mxx et 3dmox)...

        Faut que je cherche encore pour trouver les options correctes.

    • [^] # Re: Architecture Via C3

      Posté par  (site web personnel) . Évalué à 1.

      ??? C'est très très con de la part de VIA cette histoire :( CMOV est une instruction qui ne coute rien et qui évite d'utiliser des sauts briseurs de pipelines.

      "La première sécurité est la liberté"

      • [^] # Re: Architecture Via C3

        Posté par  (site web personnel) . Évalué à 1.

        On économise le silicium où on peut... Avec le C3, VIA cherchait un processeur bas cout. Les premières série (Samuel, Samuel2, Erza) n'ont pas cette instruction. Par contre, le petit dernier (Nehemiah), qui a remplace les instructions 3dmow par sse, est un i686 complet. Il est disponible sur les nouvelles EPIA M10000 (pas celles vendu il y a 3 mois)

Suivre le flux des commentaires

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