Sortie de Vala 0.1.6

Posté par (page perso) . Modéré par Amaury.
2
20
jan.
2008
Gnome
La version 0.1.6 de Vala est sortie ! Vala est un langage de programmation avec une syntaxe fortement inspirée du C# conçu pour l'environnement GNOME. Bien qu'il s'agisse d'un langage de haut niveau, possédant par exemple des patrons de classe, de l'inférence de type ou des fonctions anonymes, il est compilé en C et utilise la bibliothèque GObject de façon standard.

Bien que principalement conçu pour GNOME, le langage Vala est utilisable simplement combiné avec GLib et GObject. Le langage est de plus facilement interopérable avec d'autres bibliothèques écrites en C, pour lesquelles il suffit de créer un fichier VAPI, et utilisable depuis d'autres langages de programmation capable de s'interfacer avec le C.

Cette nouvelle version vient à point combler les manques des versions précédentes en permettant aux méthodes d'objet d'être invoquées par des signaux, en rajoutant le support de la compilation conditionnelle et en autorisant l'imbrication des types génériques. La liste des changements depuis la version 0.1.5, en plus des classiques mises à jour et autres correction de bogues, est la suivante :
  • Pointeurs vers les membres d'instance gérés pars les signaux ;
  • Support de la compilation conditionnelle ;
  • Support des types génériques imbriqués ;
  • Ajout des types size_t et ssize_t ;
  • L'option --enable-non-null entraîne l'utilisation de types non nuls par défaut ;
  • Support limité pour les types nullables ;
  • Support basique des pre- et post-conditions ;
  • Gestion de la mémoire toujours activée ;
  • Interfaces pour les bibliothèques libgnome-menu et liboobs-1.
  • # C & Cie

    Posté par . Évalué à 7.

    C++, C#, Ojective-C, Vala, ...

    Je vais sûrement passer pour le grand béotien que je suis en la matière, mais il n'y en n'aurait pas trois de trop, parmi tous ces langages ?
    • [^] # Re: C & Cie

      Posté par . Évalué à 3.

      C++ et Objetcive C sont effectivement proches.
      C# se rapproche plutot de Java que de C++.
      Vala est proche de C#, mais le compilo génère du code natif (voir le lien journal)
      • [^] # Re: C & Cie

        Posté par . Évalué à 10.

        C++ et Objective C ? proches ?

        Autant que je sache, l'approche de C++ et d'Objective C sont totalement orthogonale. Là ou Objective C apporte juste une couche objet a liaison dynamique a C, C++ est un langage a part entière, ce n'est pas une simple couche au dessus C. (se rappeler la nécessité du extern "C"). Donc, effectivement, les deux peuvent encapsuler du C, c'est fait pour, mais c'est bien le seul point commun.
        • [^] # Re: C & Cie

          Posté par . Évalué à -5.

          "orthogonale".... warf ! pourquoi pas perpendiculaire pendant que vous z'y êtes... --> [ ]
      • [^] # Re: C & Cie

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

        Vala est proche de C#, mais le compilo génère du code natif

        ben non justement, ça génère du C.
        • [^] # Re: C & Cie

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

          bah non... pas du C. Le compilo valac génère directement du a.out

          Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. \n -- Jules Claretie

          • [^] # Re: C & Cie

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

            Ça m'étonnerait, le a.out est un format totalement obsolete.

            Au moins du ELF, non ?
            • [^] # Re: C & Cie

              Posté par . Évalué à 1.

              a.out c'est juste le nom de l'exécutable produit par défaut, en quoi est-ce "obsolète" ??
              • [^] # Re: C & Cie

                Posté par . Évalué à 2.

                a.out est le nom du format d'exécutable précédent le elf.
                • [^] # Re: C & Cie

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

                  Ce n'est certainement plus du a.out, mais certains compilateurs nomment encore les fichiers comme ça quand aucun nom n'est donné par l'utilisateur.

                  C'est donc juste un nom par défaut, et plus un format d'éxécutable.
                  • [^] # Re: C & Cie

                    Posté par . Évalué à 1.

                    mais certains compilateurs nomment encore les fichiers comme ça quand aucun nom n'est donné par l'utilisateur

                    Dont gcc, qui est quand même le compilateur par défaut sous Linux !
                    Résultat de la compilation par gcc d'un source bidon :

                    $ gcc toto.c
                    $ file a.out
                    a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
      • [^] # Re: C & Cie

        Posté par . Évalué à 2.

        Java étant beaucoup plus proche de C++ que d'ObjC, j'ai un peu de mal à comprendre comment se positionne C# ;)
    • [^] # Re: C & Cie

      Posté par . Évalué à 10.

      Étant "fanboy" (comme le mot est à la mode ici) d'Objective-C, je vais vaguement essayer d'expliquer l'intérêt de ces langages.
      En un mot: C++ est une couche très épaisse au dessus du C. Objective-C est une couche très fine au dessus du C. Les implications:
      - se retrouvent en termes de complexité. Ajouter une couche Objective-C au dessus d'un compilateur C est trivial (pour l'anectode, un développeur du projet Étoilé a réecrit la couche logique (pas syntaxique) de l'objective-c en deux jours!). Ajouter le ++ au C, par contre, est un réel cauchemar pour l'implémenteur (une histoire de grammaire qui n'est plus LALR). Pour l'utilisateur, cela se ressent fortement. Le créateur du C++ a dit quelque chose du genre "je ne m'attend pas à ce que qui que ce soit comprenne le langage dans sa totalité" (c'est assez proche de la philosophie Perl: on ajoute du bloat et du bloat syntaxique et chaque développeur apprend son propre sous-langage - mis à part qu'en C++, ce sous langage est relativement commun). Personnellement, je suis (très) loin d'être une lumière, mais j'ai réussit à me coder un binding générique Objective-C <-> Python pleinement fonctionnel en quelques jours (et j'ai très eu d'expérience en Objective-C derrière moi) - en ramant plus sur la partie Python que Objective-C. Après, je ne débattrai pas plus longuement sur l'intérêt de la simplicité, la littérature abonde là dessus.
      - Une équivalence entre le C et l'Objective-C. Le C++ est vaguement capable de réutiliser ce qui est fait en C (donc C => C++ - et encore, il y a des cas assez rares où un code C ne compile pas en C++ - simple exemple: en C, tu peux avoir une variable "class". C++ réserve ce mot clef). En Objective-C également, la réutilisation du code C est à 100% possible (et sans les cas rares du C++) mais l'inverse est également vrai: même en n'ayant qu'un compilateur C sous la main il est possible de réutiliser des librairies Objective-C. Réutiliser les librairies C++ en C sans compilateur C++ est totalement exclu.
      Pour résumer, Objective-C est très proche de l'approche Unix (transparence, simplicité et couche fine) tandis que le C++ est plus proche de l'approche Windows (cacher les détails d'implémentation, préférer la complétude à la simplicité, la "couche épaisse" n'étant qu'un corollaire de ces deux derniers points)
      Vala, quant à lui, serait un Objective-C avec une couche un peu plus épaisse, ce qui lui permet d'ajouter des concepts de plus haut niveau et de s'affranchir de concepts qui seraient de trop bas niveau au goût de certains développeurs objet. Tout en restant à 100% équivalent au C, simple et transparent. Un excellent compromis à mon goût (même si la syntaxe C#-like me sort par les trous de nez :))

      C# ne vise pas à être "une couche au dessus du C" (qu'elle soit fine ou épaisse) et n'a donc rien à voir avec les autres que tu as cités. Il serait beaucoup plus proche du Java.

      Maintenant, Vala et Objective-C font ils doublons ? Oui et non. De loin, ils poursuivent les mêmes objectifs, mais de près:
      - On peut mettre directement du C dans du code Objective-C. Objective-C, en fait, n'étend que légèrement le C pour les définitions et les déclarations de classes/méthodes/fonctions (à la limite, Objective-C aurait pu être fait à coup de directives du préprocesseur. D'ailleurs, il me semble que la première implémentation d'Objective-C n'était qu'un préprocesseur), tandis que Vala est un langage à part entière.
      - Objective-C cible le C et les développeurs C. Vala cible GObject et des développeurs de "haut niveau" (garbage collector par exemple. Je sais, il y en a aussi en Objective-C, mais vu son échec retentissant...)
      Ces deux différences suffisent, AMHA, à justifier l'existence des deux en parallèle.
      Un petit bémol pour Vala, toutefois, est le fait qu'il s'appuie sur GObject dont le modèle objet est singulièrement limité comparé à l'Objective-C: pas de categories, impossibilité de surharger une méthode, réflexion limitée.

      Bon, c'est pas tout ça, mais j'étais censé bosser aujourd'hui moi, pas mouler... :-/
      • [^] # Re: C & Cie

        Posté par . Évalué à 2.

        C++ avec un bonne plateforme de développement bien complète, vraiment multi-plateformes et bien puissante derrière, il n'y a rien de tel ( qui a dit Qt4 ? ) .
        • [^] # Re: C & Cie

          Posté par . Évalué à 6.

          C'est le cas d'à peu près tous les langages (sauf peut être Brainfuck ;)), et je n'ai jamais dit que C++ était une sous merde inutilisable que seul un barbare sous l'emprise de substances illicites utiliserait, hein (c'est "l'approche windows" qui a choqué ? ce n'était pas dans un but péjoratif, c'était juste pour illustrer que philosophiquement, il y avait un gouffre énorme entre Objective-C et C++). Tout ce que mon message dit, c'est que l'Objective-C est au C++ ce que kate est à KDevelop. Je conçois et respecte que l'on puisse aimer les IDEs-usine-à-gaz, mais d'autres aiment bien les éditeurs simples et sobres.
        • [^] # Re: C & Cie

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

          N'oublions pas que Qt étend la syntaxe du C++ à l'aide de moc...
          • [^] # Re: C & Cie

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

            C'est pas tout à fait vrai...
            le moc sert à automatiser la réimplémentation de certaines fonctions de manière à simplifier la vie du développeur.
            Ce n'est absolument pas un nouveau langage comme l'est Vala.
            Le code reste du C++ pur.

            http://doc.trolltech.com/4.3/templates.html#code-generators-(...)
            • [^] # Re: C & Cie

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

              Du C++ pur, pas vraiment. Certains voient d'ailleurs ça comme un gros inconvénient, alors que d'autres (dont je suis) voient ça comme un avantage.

              Un objet C++ héritant de QObject et bénéficie grâce au travail du moc :
              - des signaux et des slots
              - de l'introspection
              - de signaux très pratiques du genre aboutToBeDeleted() et deleted()
              - d'une gestion relativement automatique de la destruction
              - de la notion de propriété (attributs qu'on peut régler sur un objet)

              Ca fait quand même pas mal de choses. Tout ça pour le prix d'une petite phase de compilation supplémentaire, gérée par le compilateur moc.

              Ces fonctionnalités en plus sont ce qui rend Qt plus facile à utiliser qu'un framework C++ standard.
              • [^] # Re: C & Cie

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

                Je dirais que Vala est à C/GObject ce que moc est à C++/Qt.

                C'est bien possible car on retrouve des trucs similaires, qui existait cependant déjà en C mais qui sont bien plus pratique (IMHO) à utiliser en Vala :

                - des signaux et des slots : depuis longtemps en GObject, très simple à utiliser en Vala grçave à l'opérateur += et sympa grace aux fonctions anonymes. bla.my_event += (foo, evt) => { stdout.printf ("bla!\n"); }

                - de l'introspection : on attend toujours gobject-introspection mais les outils sont déjà là en Vala (pour les GIDL par exemple).

                - de signaux très pratiques [..] : la gestion des signaux de GObject, avec des connect_after, connect_before, combiné aux delegates de Vala est vraiment cool.

                - d'une gestion [...] de la destruction : la gestion des références de GObject permet déjà d'avoir une gestion de la mémoire bien plus souple qu'en C de base. Vala gère ces références automatiquement (bien que tout reste paramétrable) et fait donc des appels aux destructeurs correctement.

                - de la notion de propriété : que permet aussi le GObject avec des constructeurs et accesseurs à ces propriétés configurable.

                Donc c'est vrai qu'on a toujours eu affaire à deux conceptions qui se ressemblent mais basée sur deux langages différents (le C++ pour Qt et le C pour GObject).
                • [^] # Re: C & Cie

                  Posté par . Évalué à 3.

                  la gestion des références de GObject permet déjà d'avoir une gestion de la mémoire bien plus souple qu'en C de base. Vala gère ces références automatiquement (bien que tout reste paramétrable) et fait donc des appels aux destructeurs correctement.

                  Au fait, il est capable de casser les cycles de références ?
            • [^] # Re: C & Cie

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

              Je dirais que Vala est à C/GObject ce que moc est à C++/Qt.
              • [^] # Re: C & Cie

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

                La différence c'est que Vala crée son propre langage. (il faut écrire un fichier .vala)
                le moc de Qt lis un fichier c++ en-tête (.h) standard pour générer un autre fichier .cpp standard avec la définition de la classe QMetaObject, et l'implémentation des signaux.

                Bref, ça reste du C++, ce n'est pas un nouveau langage.
      • [^] # Re: C & Cie

        Posté par . Évalué à 5.

        En un mot: C++ est une couche très épaisse au dessus du C. Objective-C est une couche très fine au dessus du C.

        Je pense que justement le C++ n'est pas une couche au dessus du C, contrairement à Objective-C. C'est un autre langage qui s'interface très facilement avec le C mais c'est plus à voir comme un autre langage. Pour illustrer mon propos, en C++, on n'utilise pas (en tout cas c'est plus que déconseillé) de chaine de charactères en char* mais des std::string, de même qu'on utilise pas de pointeurs pour faire des tableaux mais des std::vector<> (ou std::array encore en tr1). Il y a très peu de choses que l'on fait en C++ de la même manière qu'on le fait en C. Certe la sytaxe a été très largement reprise mais on est très loin du "C with classes" du début.


        Etienne
        • [^] # Re: C & Cie

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

          je pense exactement ... l'opposé...

          D'ailleurs, les std::* ne sont pas à proprement parlé du C++ mais simplement une bibliothèque écrite en c++.
          Par exemple, en QT on utilise pas std::*
          en MFC (çapu) non plus.
          Dans les softs comme InDesign (juste parce que je suis déjà allé voir) on n'utilise pas non plus la stl.

          Idem pour les tableaux, ...

          Il faut bien dissocier la stl et le C++

          Et si C++ était vraiment un nouveau langage, on aurait justement un vrai type string par exemple.


          Le C++ est au contraire une surcouche (grossière) au dessus du C
          • [^] # Re: C & Cie

            Posté par . Évalué à 5.

            D'ailleurs, les std::* ne sont pas à proprement parlé du C++ mais simplement une bibliothèque écrite en c++.

            Une implémentation de C++ qui ne fournit pas de std::string n'est pas du C++, car la STL est justement décrite dans le standard du C++.

            Le langage est composé d'une syntaxe et d'une bibliothèque standard.

            Pour prendre ton exemple des MFC, c'est exactement l'exemple où on fait non pas du C++ mais du "C with classes" et ça n'utilise de C++ que les classes (on aurait pû faire aussi dégueulasse en Objective-C soit dit en passant).

            Qu'on puisse ne pas utiliser la bibliothèque standard est vrai dans tous les langages. Mais va faire un tour sur les newsgroups (fr.)?comp.lang.c++ ou lis les livres de Bjarne Stroustrup, Herb Sutter ou Andreï Alexandrescu pour voir que le C++ est loin d'être une "simple surcouche au C" et qu'on ne programme pas du tout de la même façon en C et C++.


            Etienne
            • [^] # Re: C & Cie

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

              je sais bien qu'on ne programme pas du tout pareil en c et en c++
              Je parlais par contre d'une surcouche "grossière" dans le sens où c'est quand même pas un beau model object...

              Mais ok, je ne savais pas que la stl était dans le standard (et ça me désole un peu vu comment la stl est chiante et pas pratique - par rapport à des libs mieux faites, telles que qt...)
              • [^] # Re: C & Cie

                Posté par . Évalué à 3.

                Je parlais par contre d'une surcouche "grossière" dans le sens où c'est quand même pas un beau model object...

                C'est à dire ?
                • [^] # Re: C & Cie

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

                  C++ on continue de manipuler les types de base (char, int, ...) qui n'ont rien d'objets par exemple.

                  on fait de l'objet en C++ mais il y a quand même de plus beaux langages pour le faire (qui à dit ruby ? ;-))

                  Maintenant, il y a certaines libs (comme QT) qui permettent d'améliorer un peu (beaucoup) les choses, mais comme dit un peu plus bas, il suffit de regarder la stl et les std::string (cas le plus courant)... et la ... beurk
                  • [^] # Re: C & Cie

                    Posté par . Évalué à 1.

                    C++ on continue de manipuler les types de base (char, int, ...) qui n'ont rien d'objets par exemple.

                    Comme à peu près tous les langage, Objective-C, Java, C# et autres compris.
                    • [^] # Re: C & Cie

                      Posté par . Évalué à 1.

                      Ouai mais en Java et C#, c'est considéré commes des objets.
                      • [^] # Re: C & Cie

                        Posté par . Évalué à 2.

                        En Java, ça ne l'est que depuis récemment. (Java 1.4, peut-être ?)
                        • [^] # Re: C & Cie

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

                          Non. En Java il existe des types primitifs (int, boolean, double...) Pour chaque type primitif il existe une contrepartie Objet, un wrapper (respectivement Integer, Boolean, Double...) qui hérite du type Object. Cette dualité a été une source récurrente d'ennuis pour les développeurs depuis fort longtemps. Par exemple, alors qu'on manipule presque exclusivement les types primitifs dans le code, dans un tableau associatif (Map) il n'est pas possible d'utiliser des types primitifs pour les clés, il faut utiliser les wrappers ce qui alourdit inutilement le code source.

                          Cependant depuis Java 1.5 il existe une facilité syntaxique, appelée autoboxing, qui fait le travail de conversion entre les types primitifs et les types objets de façon transparente à la grande joie du programmeur. D'ailleurs pour information, quand on regarde le bytecode produit on se rend compte que le compilateur a généré le code nécessaire à la conversion des types.
                          • [^] # Re: C & Cie

                            Posté par . Évalué à 1.

                            Oui, donc ce n'est pas "non", c'est "oui" ;-).

                            Forcément, s'il existe des types primitifs dans un langage objet, il y a toujours moyen de les encapsuler en tant qu'atributs d'un objet, que ces classes soient définis en standard ou non. Le comportement des vieux Java reste que les types primitifs ne sont pas traités, par défaut, comme des objets, ce qui n'est plus vrai avec l'autoboxing.
                      • [^] # Re: C & Cie

                        Posté par . Évalué à 2.

                        A quoi sert la classe Integer si int est considéré comme un objet ?
                      • [^] # Re: C & Cie

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

                        Non désolé.

                        int en java, c'est un type non objet. Integer est un objet autour de int.
                        en C#, la documentation de la MSDN indique que int est un mot clé correspondant en C à un int32_t. (Même remarque pour char et autres types natifs).

                        Dans ces deux cas, ils ne dérivent en rien d'Object et ne sont absolument pas des objets. Faut arrêter la désinformation à un moment ...
                        • [^] # Re: C & Cie

                          Posté par . Évalué à 0.

                          Bah mon visual studio, il a plutot tendance à me dire que c'est un objet.
                          Dans mes souvenirs, les types primitifs sont traités avec de l'autoboxing : http://en.wikipedia.org/wiki/Object_type.
                          • [^] # Re: C & Cie

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

                            La MSDN indique clairement que ce sont 1/ des types primitifs 2/ des mots clés du langage. En aucun cas des objets.

                            Documentation du mot clé int
                            http://msdn2.microsoft.com/fr-fr/library/5kzh1b5w.aspx

                            Liste des mots clés
                            http://msdn2.microsoft.com/fr-fr/library/x53a06bb.aspx
                            • [^] # Re: C & Cie

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

                              MSDN indique clairement que ce sont 1/ des types primitifs
                              Ca c'est de la désinformation. Je te mets au défi de trouver le terme 'primitif' dans la page que tu cites.
                              Dans la page que tu références, il est indiqué que int désignait un type intégral.
                              Qu'est-ce qu'un type intégral ? Un type numérique.
                              Qu'est-ce qu'un type numérique ? C'est un type simple.
                              Qu'est-ce qu'un type simple ? Un type struct.
                              Qu'est-ce qu'un type struct ? Un type valeur.
                              Qu'est-ce qu'un type valeur ? un type.
                              (Tout cela découle de la lecture de la grammaire du langage)
                              Autre citation qui montre clairement que les mots clés ne sont que des raccourcis syntaxique :
                              "The simple types are identified through reserved words, but these reserved words are simply aliases for predefined struct types in the System namespace".
                              Dernière citation :
                              "C#’s type system is unified such that a value of any type can be treated as an object. Every type in C# directly or indirectly derives from the object class type, and object is the ultimate base class of all types."

                              Source : http://download.microsoft.com/download/3/8/8/388e7205-bc10-4(...)
                        • [^] # Re: C & Cie

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

                          Désinformation désinformation, faut pas en rajouter non plus :)
                          En C# int est effectivement un mot clé... Mais ca ne l'empêche pas d'être un objet non plus :)
                          Sémantiquement c'est équivalent à une déclaration d'un objet de type Int32, qui dérive explicitement de Object.
                          En C# il y a 2 types d'objets : les objets "valeur" et les objets "référence". Le premier type inclu tous les types primitifs tels que int, double, char, et les types déclarées comme "structure" à l'aide du mot clé "struct". Les autres sont les types déclarées comme "class", ca n'empêche pas certains mot-clés d'également référencer ce genre de type, exemple le mot-clé "string" qui est un raccourci pour "String", classe tout ce qu'il y a de plus standard.
                          Si t'es pas convaincu, exécute le code suivant en C# :
                          int i = 0;
                          Console.WriteLine(i is object);
                          Le résultat est bien évidemment True, encore heureux.
                          Moralité, en C# tout dérive d'Object, il y a 2 types d'objets : les classes et les structures.
                          • [^] # Re: C & Cie

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

                            Désolé alors et merci pour l'explication. La lecture de la doc m'ayant indiqué que c'etait un mot clé, j'en avais déduit qu'il s'agissait d'un truc spécial, probablement pas objet mais à priori ce n'est qu'un sucre syntaxique.

                            Personnellement je trouve dommage de rajouter des mots clés "inutiles" comme ça mais bon au moins le modèle objet est "cohérent".
                            • [^] # Re: C & Cie

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

                              Effectivement il peut y avoir une confusion.
                              Ces mots clés existent probablement pour 2 raisons :
                              - syntaxe plus concise, int par exemple designant le type "System.Int32".
                              - proche de la syntaxe C/C++, ce qui est un des objectifs de C#.
                              • [^] # Re: C & Cie

                                Posté par . Évalué à 1.

                                Bonjour,
                                puisque j'ai des pros sous la main, il y a un truc que je ne comprends pas bien (j'aime bien lire des livres sur les langages mais je ne programme pas, je ne connais rien donc) :

                                si int est un objet, alors dans un code tel que
                                int i;
                                \debut_boucle
                                ...
                                i =+ 1;
                                \fin_boucle
                                à chaque tour de la boucle un nouvel objet est créé et une nouvelle affectation est effectuée, non ?
                                Ça doit être assez consommateur de ressource !
                                À mes yeux (qui ne s'y connaissent pas plus que moi) cela justifierait l'existence de types primitifs comme en Java.

                                Que se passe-t-il en fait ?
                                • [^] # Re: C & Cie

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

                                  En fait en C# il y a les types objets "valeurs" et les types objets "références".
                                  En l'occurence un int est un type valeur. Donc concrêtement dans l'exemple que tu cites, un espace (de 32 bits en C#) sur la pile va être réservé pour stocker la variable 'i', et seul son contenu sera modifié à chaque nouvelle affectation dans la boucle. Pas de nouvelle allocation donc.
                                  Ca correspond un peu aux types primitifs en Java, à la différence qu'il n'y avait pas d'unification entre les types primitifs et les autres mais une séparation nette, contrairement à C#, qui a montré qu'on pouvait très bien tout considérer comme des objets avec des propriétés communes sans pour autant oublier la notion de types "valeur" qui améliorent grandement les perfs.
                                  • [^] # Re: C & Cie

                                    Posté par . Évalué à 1.

                                    ok, c'est clair merci.

                                    Je suis en train de lire un livre sur python et apparemment, un nouvel objet et une nouvelle affection sont créés à chaque fois (un entier étant non modifiable) dans la situation décrite.
                                    Pourquoi avoir donc introduit ainsi ce type non modifiable ? On perd en performances non ?

                                    Merci pour les réponses.
                                    • [^] # Re: C & Cie

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

                                      En fait en Python c'est pareil qu'en Java ou C# :)
                                      Les types immutables en Python sont grosso modo là pour cacher ce que les types primitifs cachent en Java ou les types valeurs en C#. (c'est un racourci mais ca suffit pour ce qui nous intéresse).
                                      Dans la sémantique exprimée par le langage Python, cela donne effectivement l'impression qu'il y a création d'un nouvel objet à chaque manipulation. En réalité l'interpréteur fait la même chose qu'en C# ou Java, à savoir des opérations sur des valeurs. L'objet est justement immutable pour cacher cette optimisation.
                                      Si un entier était modifiable, il devrait être référencé en permanence par un "pointeur" (comme les autres types qui sont manipuler à travers un pointeur/adresse en interne), ce qui nécessite un intermédiaire : il faut faire un accès à une adresse mémoire pour obtenir le pointeur puis un autre accès mémoire pour accéder à la valeur référencé par le pointeur, ce dernier accès étant plus lent car effectué dans une autre partie de la mémoire. Si t'es dans une opération de type a = b + c, faut faire 3 fois ce boulot !
                                      Je sais pas si je suis clair :)
                                      Par contre ce que je dis là n'est pas vrai pour les types immutables qui ne sont pas "optimisés", cad qui ne cache pas des manipulations de valeur. Par exemple le type String.est en Java, C# ou Python un truc "immutable", il n'est pas pour autant utlisé en tant que valeur mais en tant que référence, pour la simple et bonne raison que la valeur contient beaucoup de données (plusieurs caractères) et de taille variable : les passer par valeur d'une méthode à une autre par exemple nécessiterait systématiquement une copie de l'intégralité des données, c'est moins coûteux de passer uniquement la référence (qui elle est stockée sous la forme d'une adresse).
                                      Si ces types sont immutables, ce n'est pas cette fois pour cacher une optimisation du type manipulation de valeur à la place de manipulation de référence. C'est plus pour éviter au programmeur de faire n'importe quoi en manipulant le contenue d'une chaîne.
                                      Du coup là par contre ca peut devenir très couteux de faire des opérations sur des chaînes de caractères, style :
                                      string a = "rezzef"
                                      a += "suite"
                                      a += "suite2"
                                      a += "ligne3"
                                      Là effectivement il y a création systématique d'un nouvel objet pour stocker le résultat de la concaténation, ce qui est coûteux.
                                      Des langages comme C# ou Java propose des classes qui cachent des chaînes de caractères "modifiables" quand c'est nécessaire (typiquement pour l'exemple ci dessus) :
                                      StringBuilder sb = new StringBuilder("rezzef")
                                      sb.Append("suite")
                                      sb.Append("suite2")
                                      sb.Append("ligne3")
                                      string res = sb.ToString()
                                      Dans cet exemple l'objet sb n'est pas immutable, et les appels successifs à la méthode Append modifie le contenue de la chaîne de caractère qui est stockée en interne (probablement dans un tableau de caractère), le dernier appelle permet de recopier le contenu dans une "string" classique.
        • [^] # Re: C & Cie

          Posté par . Évalué à 2.

          En même temps, je ne sais pas s'ils ont fini par améliorer les choses et fournir une stdlib digne de ce nom, mais les std::string c'est juste une surcouche assez pauvre au-dessus d'un char* (et quand je faisais du C++ je devais régulièrement reprendre ce char* pour faire des opérations sur les chaînes, à cause de la merdicité absolue de l'API std::string).
          • [^] # Re: C & Cie

            Posté par . Évalué à 2.

            Le concept de la stl est de separer les containers et les fonctions de manipulations. Donc la classe std::string ne contient pas énormément de fonctions, il faut regarder du côtés de fonctions et fonctors de la stl.
            Par exemple si je veux trier une std::list, un std::vector ou un autre container sequentiel, je ferais de la même façon

            std::sort(container.begin(), container.end());

            Comme ceci, je peux utiliser le container qui est le plus adapté (fournit par la stl ou un autre). C'est sans doute cela qui est déroutant quand on n'est pas habitué.


            Le reproche que je fais à la stl c'est de n'être pas assez complète, ceci étant dû à la façon de faire évoluer le standard au sein du commité. C'est pour celà qu'on a très souvent recours à un bibliothèque comme boost (dont certains éléments passe dans le standard comme les shared_ptr).
            • [^] # Re: C & Cie

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

              ben vi mais c'est justement là qu'on se rencontre des limites du modèle objet dans c++ (puisqu'on y inclus la stl)

              "logiquement" dans un modèle objet, on ferait :
              container.sort()


              Dans ton cas on a tout simplement une _fonction_ sort qui prend un container...
              • [^] # Re: C & Cie

                Posté par . Évalué à 3.

                On n'a pas une fonction sort qui prend un container, on a une fonction sort qui prend 2 itérateurs et une fonction de comparaison (std::less par défaut). C'est le principe de la stl de travailler sur des containers et je conçois qu'on puisse trouver ça discutable et pas intuitif mais c'est aussi beaucoup plus puissant.

                Je ne vois pas trop ce que tu entend par "modèle objet dans c++", la STL est ce qu'elle est pour privilégier les souplesse et les performances, la STL utilise de façon très intensive les templates plutôt que l'héritage et les fonctions virtuelles pour gérer la généricité car, la résolution se faisant à la compilation, c'est beaucoup plus rapide.

                Pour prendre un exemple, pour tous les containers on peut fournir son propre allocateur de mémoire. Pour "faire plus objet", on aurait pus avoir à fournir au constructeur une instance d'une classe héritant de IAllocator, ce qui aurait induit un appel à une fonction virtuelle pour chaque allocation. Le choix qui a été fait est de fournir une classe en paramètre template, ce qui permet de déterminer l'appel de fonction dès la compilation.


                Le C++ permet d'utiliser plusieurs paradigmes pour la généricité, la STL a fait le choix d'utiliser les templates ça ne veut pas dire qu'on ne peux pas utiliser autre chose et qu'on ne peux pas coder de façon plus "orienté objet" en C++.
                • [^] # Re: C & Cie

                  Posté par . Évalué à 1.

                  Ce qu'il entend par la, c'est que le tri de la stl tel que presente n'est pas de l'objet mais de l'imperatif.

                  Un modele de tri oriente objet aurait place la fonction sort() dans la classe du container.

                  La c'est de l'imperatif tout ballot, pas de l'objet.
                  • [^] # Re: C & Cie

                    Posté par . Évalué à 3.

                    Oui c'est de l'impératif car dans cette situation c'est la meilleurs choses et ça te permet de trier n'importe quel container sur n'importe quel type auquel tu peux fournir une fonction de comparaison.

                    Ce n'est pas une limite du modèle objet c'est un choix de ne pas l'utiliser dans certains cas.

                    Si on n'avait pas de template aussi puissant en C++, nul doute que la librairie standard aurait ressemblé d'avantage à QtCore, mais il se trouve que, en plus du modèle objet, on dispose de mechanismes particulièrement puissants qui ont été utilisés.
                    • [^] # Re: C & Cie

                      Posté par . Évalué à 1.

                      L'approche objet te permet aussi de trier n'importe quel container sur n'importe quel type (c'est ce qui est fait en java via la classe Arrays + l'objet de tri implementant Comparator).

                      Apres, les considerations d'optimisation, je rentrerais pas la dedans, je ne suis pas assez cale en c++ pour pouvoir donner un avis pertinent.

                      L'avantage de l'approche objet est qu'elle te donne un modele "consistent" sur tout ton langage.
                      La tu vas melanger de l'imperatif a tes propres objets.

                      Bon, je sais, c'est un peu le concept du C++, mais c'est precisement ce qui deplait a nombre de developpeurs (moi le premier).

                      Apres, les gouts et les couleurs, hein...
                      • [^] # Re: C & Cie

                        Posté par . Évalué à 3.

                        J'ai peut être pas tout compris, mais il me semble pas que java soit différent à ce niveau.
                        Les tris sont fait dans des méthodes statiques dans les classes Collections ou Arrays, on appelle alors ces "fonctions" sort sur le container, du genre
                        Collections.sort(monContainer)
                        (avec la responsabilité de l'ordre dans les objets contenus) oubien
                        Collections.sort(monContainer, monComparateur)
                        si on veut utiliser un ordre différent.
                        • [^] # Re: C & Cie

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

                          Pareil, je vois psa bien la différence entre le java et le C++ sur cette question.
                          En C++, si on veut utiliser un comparateur spécialisé on utilise un object foncteur qui fait ça comme en java, et on le passe à sort (comme en java quoi).

                          std::sort dans l'esprit, c'est une méthode statique d'Iterator. Aucune différence par rapport à java.

                          Peut-on m'expliquer la différence intrasèque ?

                          Enfin bon le modèle objet de C++ est probablement pas le plus pur, surement par cette volonté d'être multiparadigme. Quand à celui de java, il n'a aucune excuse mais il n'est pas bien meilleur.
                          • [^] # Re: C & Cie

                            Posté par . Évalué à 2.

                            Peut-on m'expliquer la différence intrasèque ?

                            Je connais très peu java, l'impression que j'en ai est que la seule différence c'est qu'en Java, l'opérateur de comparaison doit faire des casts vers l'objet à comparer là où le C++, resolvant le type à la compilation ne le fait pas (par extension, le C++ n'a pas besoin non plus besoin que la classe à trier hérite de la class List mais qu'à la compilation on trouve les fonctions dont l'algorithme à besoin). Sinon il semble bien que ce soit identique.
                        • [^] # Re: C & Cie

                          Posté par . Évalué à 0.

                          Ben si, java est different, sort est une methode d'une classe, ce qui est pas le cas pour la stl (fonction dans l'espace de nommage std).
                          • [^] # Re: C & Cie

                            Posté par . Évalué à 1.

                            C'est une méthode d'une classe dont toutes les méthodes sont statiques. En gros c'est un agrégat de fonctions, un peu à la manière de la classe java.lang.Math.
                            Ce n'est donc pas du tout la même chose que d'avoir maCollection.sort()
                            • [^] # Re: C & Cie

                              Posté par . Évalué à 0.

                              Ce n'est donc pas du tout la même chose que d'avoir maCollection.sort()

                              Non, effectivement.

                              Mais c'est pas la meme chose non plus qu'une fonction d'un espace de nommage.
                              Ca reste une methode d'une classe.
                              • [^] # Re: C & Cie

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

                                J'hesite entre branlette intellectuelle et nazisme objet (ce qui est globalement la même chose) pour qualifier la différence. Enfin comme qui dirait, si ca vous fait plaisir :)

                                Sémantiquement, c'est la même chose sinon. C'est un ensemble de fonctions travaillant sur des objets d'une certaine catégorie. Y'en a un qui est encapsulé dans une classe, et l'autre dans un namespace, mais au final, ca reste strictement la même chose. (on pourrait à la rigueur argué d'avoir un namespace un peu plus poussé genre std::collection::sort mais bon vu la taille de la STL, c'est à mon avis contre productif (la STL c'est petit pour une librairie standard, pas besoin d'avoir 3 milliards niveaux de namespaces)).
                                • [^] # Re: C & Cie

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

                                  Il y a quand même des différences entre une fonction "globale" et une méthode.
                                  Une méthode est raccrochée à une classe, cela lui offre des fonctionnalités particulières qui fait justement tout l'intérêt de la programmation objet :
                                  - l'encapsulation : la méthode a accès des champs privés de la classe, contrairement à une fonction externe. Bref on peut exposer des actions (méthodes), sans exposer les détails d'implémentation internes de la classe.
                                  - l'héritage : une méthode peut être redéfinie par une sous-classe et modifier le comportement de l'action attendue.
                                  Une méthode suppose l'existance d'une instance à manipuler, ce qui explique la syntaxe toto.Foo().
                                  • [^] # Re: C & Cie

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

                                    Donc dans le cas présent c'est bien de la branlette intellectuelle.

                                    On parle ici d'un ensemble de fonctions regroupée soit dans un namespace, soit dans une classe qui ne fait que ça. Tu peux remplace namecpace par class pour le c++ et réobtenir la même chose qu'en java. De même que si java avait des namespace, on pourrait définir Collections comme un namespace plustôt que comme une classe.

                                    - l'encapsulation : Les fonctions que tu met dans un namespace on aussi acces au autres champs de celui-ci et ce ne sont pas que des fonctions. Mais de toute façons, la classe collections en java n'est pas instanciée, tout du moin pas plusieurs fois, l'utilisation de champs privés est donc comparable à l'utilisation de variables globales vaguement cachées, ce qui veux dire de nombreux problème si tu utilise des threads.

                                    - l'héritage : Tu connais vraiment beaucoup de monde qui dérive la classe Collections ? Personnellement je n'y voit pas vraiment d'intérets...

                                    Les fonctionalitées particulières des classes sur les namespaces sont inutiles pour des cas commes "Collections" tout simplement par ce que dans ce genre de cas les classes ne servent qu'a regrouper un ensemble de fonctions pour former un tout cohérent et bien rangé, c'est à dire que l'on utilise les classes pour émuler les namespaces.
                                    • [^] # Re: C & Cie

                                      Posté par . Évalué à 1.

                                      Pour l'heritage de Collections et Arrays, pas possible de toutes facons.
                                      Le constructeur pere est definit private, donc pas appelable, et donc ta classe ne compile pas car pas possible d'appeler super.
                    • [^] # Re: C & Cie

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

                      Ce n'est pas une limite du modèle objet c'est un choix de ne pas l'utiliser dans certains cas.

                      Bon, je crois qu'on va arrêter ici puisque c'est exactement ce que je dis...
                      Parfois ils utilisent un modèle objet, d'autres fois non (quelqu'en soient les causes) et c'est bien ça qui fait que c'est bancal...
                  • [^] # Re: C & Cie

                    Posté par . Évalué à 2.

                    La c'est de l'imperatif tout ballot, pas de l'objet.

                    J'adore les gens qui se pincent le nez face à l'« impératif tout ballot ». On dirait les membres d'une église qui ont appris le dogme par coeur. La faiblesse de C++ n'a rien à voir avec ce genre de soi-disant défauts.
                    • [^] # Re: C & Cie

                      Posté par . Évalué à 3.

                      En l'occurence c'est autant du fonctionnel que de l'impératif ... une fonction générique (d'ordre supérieur) qui utilise une fonction passée en paramètre (la fonction de comparaison) pour faire son truc ...
                • [^] # Re: C & Cie

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

                  là je sais plus comment expliquer
                  Je ne dis pas que C++ c'est bien ou pas (même si je pense que C++ est pas vraiment un bon langage, il est qd même parfois sympa)
                  Mais tu l'explique même dans ton commentaire.
                  C++/stl a fait des choix, et ils privilégient les templates plutôt que l'héritage (en partie je pense parce que les interfaces n'existent pas en tant que telles)
                  Ca en fait un modèle un peu bancal, un coup on a un objet, un coup on a un template, ...
                  Ce n'est pas un modèle cohérent.

                  Evidemment on peut faire de l'objet en C++ (comme dit, il suffit de voir ce qu'en a fait qt), mais si on utilise juste C++ (et donc aussi STL) on se retrouve avec des constructions non objet au milieu (car comme tu le dit ça n'utilise pas toujours l'héritage)

                  Alors oui, téchniquement ça peut avoir des avantages, mais ce n'est pas là le problème ;-)
                  • [^] # Re: C & Cie

                    Posté par . Évalué à 3.

                    C++/stl a fait des choix, et ils privilégient les templates plutôt que l'héritage (en partie je pense parce que les interfaces n'existent pas en tant que telles)
                    C'est faux, la généricité n'est pas du tout la même avec des interfaces et des templates.

                    Ca en fait un modèle un peu bancal, un coup on a un objet, un coup on a un template, ...
                    C'est un langage multi-paradigme et on utilise celui qui correspond le mieux à l'endroit où on en a besoin. D'ailleurs la STL ce n'est pas un coup un objet un coup un template c'est des templates partout.

                    Ta critique revient à dire que, par exemple, on ne devrait pas mélanger le multithreading et le multiprocess, mais chaque chose a son avantage dans différentes situations et pour des problématiques différentes.
                    • [^] # Re: C & Cie

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

                      D'ailleurs la STL ce n'est pas un coup un objet un coup un template c'est des templates partout.

                      C'est bien là le "problème"...

                      Ta critique revient à dire que, par exemple, on ne devrait pas mélanger le multithreading et le multiprocess, mais chaque chose a son avantage dans différentes situations et pour des problématiques différentes.

                      Non pas du tout, je ne dis pas qu'il ne faut pas mélanger les genres, simplement que _ce_ mélange (objet et non-objet) je ne le trouve pas beau ni cohérent ni consistant.
                    • [^] # Re: C & Cie

                      Posté par . Évalué à 2.

                      C'est faux, la généricité n'est pas du tout la même avec des interfaces et des templates.

                      Peux-tu détailler un tout petit peu ?

                      je suis la conversation avec intérêt et ne suis pas (encore ? ;-) ) assez calé pour y participer.
                      • [^] # Re: C & Cie

                        Posté par . Évalué à 3.

                        C'est simplement que ce n'est pas la même technique, chacun apportant une réponse à des cas particuliers, en particulier ce qui justifie l'utilisation des templates c'est que dès la compilation, on sait quelles méthodes vont être appelées. Si on reprend l'algorithme de tri, avec des interfaces on a vu qu'on utilisait un une classe héritant de Comparator qui est une interface, si je veux implémenter mon propre comparator, je ferai :


                        class MonComparator : public Comparator
                        {
                        int compare(Object o1, Object o2)
                        {
                        /* le code qui fait la comparaison */
                        }
                        };

                        Pour trier on va alors instancier un objet MonComparator et le passer à la fonction Collection.sort().


                        Avec les templates, l'algorithme std::sort prend en paramètre une fonction, non pas un pointeur de fonction comme c'est le cas en C avec la fonction qsort mais un nom de fonction, le compilateur étant en charge de générer le code avec la bonne fonction. la declaration de std::sort ressemble à ça :

                        template <typename Iterator, typename Compare>
                        void sort (Iterator first, Iterator end, Compare comp);

                        Si je veux créer mon propre comparateur, je vais écrire :
                        struct MonComparateur
                        {
                        bool operator()(int i1, int i2)
                        {
                        /* code de comparaison */
                        }
                        };


                        Pour trier on va alors faire

                        std::sort(collection.begin(), collection.end(), MonComparateur());


                        A la compilation, on déclare une nouvelle fonction sort qui prend en troisième paramètre une classe de type MonComparateur.

                        Les différence entre les deux approches :
                        - La principale c'est que l'approche template implémente une nouvelle fonction std::sort pour chaque types de paramètres différents, si je réutilise ma fonction std::sort() avec un autre comparateur (std::less par exemple), j'aurai une deuxième fonction sort prenant des paramêtres différents.
                        - Avec les templates, mon comparateur compare directement le type qu'il souhaite et n'a pas besoin de "caster" les Object vers le type souhaiter, on a donc une erreur dès la compilation en cas d'utilisation d'un comparateur sur un mauvais type (ceci n'est plus vrai il me semble en Java5 et en .Net2, l'interface Comparator étant une interface generique qui prend en paramètre le type comparé).


                        C'est vraiment important de saisir qu'avec les template, à chaque appel à une fonction avec des paramêtre différent, le compilateur crée un nouvelle fonction qui s'appel de la même façon que si elle était apellée directement.

                        C'est un exemple volontairement simple qui ne couvre pas tout ce qu'on peut faire ni avec l'héritage, ni avec les templates mais qui, je l'espère, permet de saisir la différence technique.
                        • [^] # Re: C & Cie

                          Posté par . Évalué à 2.

                          Ok merci beaucoup pour ce post très explicatif, on voit bien la différence essentielle entre les deux.

                          Maintenant comment différencier les cas dans lesquels une approche est plus pertinente que l'autre ? De ce que j'en ai saisi, dans un cas on a un code compilé plus gros (cas des templates), dans l'autre il faut dynamiquement trouver quelle est la fonction utiliser (pouvant donner lieu à erreur détectable seulement à l'exécution). Stroustrup parle de polymorphisme, de compilation pour les templates et d'exécution pour les interfaces.

                          La première approche semble donc préférable pour des raisons de rapidité d'exécution, mais n'ayant pas l'expérience de la chose y a-t-il des cas, en C++, dans lesquels l'approche interface est plus appropriée ?
                          • [^] # Re: C & Cie

                            Posté par . Évalué à 3.

                            La première approche semble donc préférable pour des raisons de rapidité d'exécution, mais n'ayant pas l'expérience de la chose y a-t-il des cas, en C++, dans lesquels l'approche interface est plus appropriée ?

                            A partir du moment où tu n'as pas toutes les informations disponibles au moment de la compilation, tu ne peux pas utiliser les templates. Les interfaces se justifient pleinement lorsque le comportement doit s'adapter au cours de l'execution. Par exemple si tes objets sont créés par une Factory, tu ne sais pas précisément quel type tu manipule et tu dois donc utiliser des interfaces.
            • [^] # Re: C & Cie

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

              Concernant les strings, la STL fait la même erreur que le C : elle les traite strictement comme un tableau de caractères. Certe, elle fait ça mieux que le C, puisque tu peux manipuler des tchar mais au final, il lui manque toujours des fonctions pratiques et communes à toute lib string qui se respecte. Au hasard :
              - découpage d'une string en liste de string avec un token
              - recollage d'une liste de string avec un token
              - mise en majuscule, mise en minuscule
              - conversion UTF8, latin1, UCS16

              Quand tu manipule des strings t'as souvent besoin de faire ça et même en général un peu plus. Mais en STL, en dehors de pouvoir choisir ton algorithme de tri générique de ta chaîne de caractères, t'es super limité. Et honnêtement, trier des chaînes, je le fais moins souvent que les découper en fonction d'un token.
              • [^] # Re: C & Cie

                Posté par . Évalué à 2.

                Et honnêtement, trier des chaînes, je le fais moins souvent que les découper en fonction d'un token.

                Je suis pas là pour faire un cours de C++ mais ce que tu me dis là se résout par exemple en utilisant un std::stringstream pour voir ta chaine de charactère comme un flux puis utiliser std::getline en lui fournissant ton token. Pour assembler par exemple un vecteur de strings en une seule string séparée par un token, tu vas utiliser std::copy avec un std::ostream_iterator. Il est vrai que ça demande d'être familier avec les différents composants fournis par la STL pour pouvoir jongler avec et que c'est plus long à apprendre que QtCore par exemple.

                La STL n'a pas vocation à prévoir tous les usages. Si je prend l'exemple de Qt, la classe QString me fournie les fonctions toUtf8(), toAscii() et quelques autres, bien sûr elle ne founit pas sous forme de fonctions membre tous les encodages possible. Avec la STL, il faudra passer par un std::copy() par exemple et fournir un functor qui convertis d'un encodage à un autre, mais tout est fait pour être générique.
                Je comprend qu'on ne soit pas familier avec ce genre de chose et qu'on préfère avoir des fonctions membres pour tous les usages mais ce n'est pas la philosophie de la STL. En même temps libre à chacun de ne pas l'utiliser mais c'est souvent plus à cause de la trop grande généricité qu'à cause d'une vrai impossibilité.


                Etienne
                • [^] # Re: C & Cie

                  Posté par . Évalué à 2.

                  Merci pour ce "cours", c'est tres instructif.

                  Effectivement, je pense qu'on tombe dans ce cas sur le probleme du "c'est trop puissant pour que le dev lambda l'utilise" (je ne connaissais pas, mais je ne suis pas non plus un spécialiste du C++).

                  Je suis tombé sur le meme dilemme l'autre jour, en Javascript, ou je voulais utiliser une fonction bind() faite maison, qui en gros fait du currying. Mais j'ai hésité en pensant que ceux qui allaient réutiliser mon code ne comprendraient rien, meme si c'est une maniere de faire tres puissante qui facilite beaucoup de choses.
                • [^] # Re: C & Cie

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

                  << Je comprend qu'on ne soit pas familier avec ce genre de chose et qu'on préfère avoir des fonctions membres pour tous les usages mais ce n'est pas la philosophie de la STL. En même temps libre à chacun de ne pas l'utiliser mais c'est souvent plus à cause de la trop grande généricité qu'à cause d'une vrai impossibilité.>>

                  C'est bien la le problème. La STL ne répond pas a des besoins pratiques. C'est une belle abstraction en générale, mais des qu'on veut l'utiliser concrètement, c'est lourd. Ca me fait plus penser à un concept mathématique que à une bibliothèque destinée à la programmation.

                  Je fais la comparaison avec la QTL (Qt Template Library) qui au contraire est très orientée vers un usage quotidien et contient en dur les fonctions dont tu as besoin très souvent, et contient facilement accessible des fonctions moins usitées. Au passage, la QTL est compatible avec les iterateurs de la STL donc tu peux mixer les deux allègrement. Et certaines versions de la QTL sont plus rapides pour un usage "standard".

                  Globalement, la standardisation du C++ prend la direction d'un langage extrêmement complexe avec du branlage de mouche à différentes étapes (par exemple, il faut lire un ou deux bouquins pour apprendre à gérer correctement les exceptions générées à l'intérieur d'un constructeur). Au final, très peu de gens comprennent réellement le C++ (et je suis heureux d'en être - je veux dire, de ceux qui ne comprennent pas). La plupart des gens utilisent les fonctionnalités de base, on pourrait dire les fonctionnalités qu'on retrouve dans Java.

                  Faire du template meta-programming, typiquement, c'est un bel exercice intellectuel et boost ou la stl montre qu'on peut faire des choses chiadées avec. Sauf que :
                  - seul 1 programmeur sur 100 sera capable de comprendre le code
                  - très peu de compilateurs sont suffisamment compatibles pour fonctionner correctement avec du template meta-programming
                  - on s'aperçoit que dans d'autres langages, on fait tout aussi bien tout en restant lisible par les autres programmeurs. Au hasard, des programmes qu'on ne peut pas écrire autrement qu'en faisant du template meta-programming en C++ s'écrivent très simplement en python.

                  Finalement, je ne comprends pas la finalité de la direction actuelle de ce langage. Soit c'est pour faire des trucs originaux et nouveaux, mais dans ce cas, autant se tourner vers des langages ou on a de la latitude pour ajouter des nouveau concepts : eiffel, OCaml, Lisp, Lissac, ... Soit c'est pour faire un langage pratique, mais dans ce cas, la complexité de la gestion des exceptions ou de la programmation par template, ou bien les manques pratiques de la STL ne sont pas justifiés.
                  • [^] # Re: C & Cie

                    Posté par . Évalué à 2.

                    Au hasard, des programmes qu'on ne peut pas écrire autrement qu'en faisant du template meta-programming en C++ s'écrivent très simplement en python.

                    Juste sur ce point, je rappel juste que python est un langage au typage dynamique, ce qui fait que si tu passe un objet du mauvais type à ta fonction, tu as une erreur à l'execution. En C++ tu as une erreur à la compilation.
            • [^] # Re: C & Cie

              Posté par . Évalué à 2.

              std::sort marche pas avec une std::list, faut utiliser std::list::sort() :o)
              J'ai compris, je sors -->[]

              Le C++ n'a pas pour objectif d'être le langage le plus élégant, mais d'être un bon compromis entre efficacité et abstraction. La STL reflète ce choix.
              Le C++ c'est un peu l'AK-47 de la programmation système, une arme rustique, fiable et robuste mais surtout vachement efficace pour dézinguer sa problématique
            • [^] # Re: C & Cie

              Posté par . Évalué à 1.

              Donc la classe std::string ne contient pas énormément de fonctions, il faut regarder du côtés de fonctions et fonctors de la stl.

              C'est ridicule comme justification, une chaîne de caractères n'est pas un conteneur comme les autres et ne mérite pas les mêmes méthodes que, disons, une liste ou une table hash. Voilà ce qui arrive quand on généralise à outrance selon de vagues caractéristiques communes ("foolish consistency is the hobgoblin of little minds").
        • [^] # Re: C & Cie

          Posté par . Évalué à 3.

          > en C++, on n'utilise pas de chaine de charactères en char*
          Tu veux dire, comme avec std::fstream ? :)
    • [^] # Re: C & Cie

      Posté par . Évalué à 9.

      C++, C#, Ojective-C, Vala, ...

      Je vais sûrement passer pour le grand béotien que je suis en la matière, mais il n'y en n'aurait pas trois de trop, parmi tous ces langages ?

      Tiens c'est marrant ça, moi j'en vois 4 de trop.
  • # langage de haut niveau?

    Posté par . Évalué à 6.

    C'est bizarre, mais on parle de langage de haut niveau, et ensuite le changelog parle de pointeurs. Pour moi c'est un peu incompatible, non?
    • [^] # Re: langage de haut niveau?

      Posté par . Évalué à 0.

      Ben c'est pas obligé de les utiliser :


      Pointers

      IF YOU ARE RELYING ON WHAT I'VE WRITTEN IN THIS SECTION: DO NOT USE POINTERS YET.

      (vala tutorial)
    • [^] # Re: langage de haut niveau?

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

      Pour info la couche GLib fournit la notion de pointeur. Afin de conserver toutes les possibilitées de la GLib dans Vala, la structure 'pointer' a été conservé.

      Pour info on n'utilise cette structure que rarement car l'intérêt en est limité (juste pour des questions de performances).

      Mon petit projet à moi en Vala:
      [http://code.google.com/p/vala-benchmarks/]
      Implémentation de quelques benchs du shootout benchmark en Vala et comparaison avec Mono et C.
      • [^] # Re: langage de haut niveau?

        Posté par . Évalué à 1.

        Pour info on n'utilise cette structure que rarement car l'intérêt en est limité (juste pour des questions de performances).

        C'est ça les "TreeNode#" dans ton programme ?
        • [^] # Re: langage de haut niveau?

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

          Pas tout à fait le # indique que tu passe par référence. Dans cette classe je n'ai pas eu à utilise de 'free()' alors que si tu utilise un pointeur, tu fait vraiment ce que tu veut.

          Effectivement pour ce programme la performance est importante c'est pour ça que la classe TreeNode n'hérite pas de Object ce qui désactive la gestion de la mémoire (references counting).

          Le tutoriel explique bien la notion de pointeur, elle est très proche du C et permet de spécifier à quel endroit précis du code tu décide de libérer la variable.
      • [^] # Re: langage de haut niveau?

        Posté par . Évalué à 3.

        Mon petit projet à moi en Vala:
        [http://code.google.com/p/vala-benchmarks/]
        Implémentation de quelques benchs du shootout benchmark en Vala et comparaison avec Mono et C.


        Juste une question à la con :
        Je crois que vala était destiné à faire des appli gnome, c'est à dire des appli qui font soit de l'IHM soit de l'accès aux ressources (accès fichier, configuration wifi, ...).
        Et qu'est ce que l'on trouve dans les bench ? Des trucs purement algorithmique...

        PS : d'ailleurs la comparaison de partialsums est intéressante http://vala-benchmarks.googlecode.com/svn/trunk/partialSums/(...)
        C'est quasiment le même code.
        • [^] # Re: langage de haut niveau?

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

          Vala est avant tout destiné à créer des composants logiciels en utilisant les conventions GObject c'est dire tout ce qui tourne autour du monde de Gnome. Ces composant logiciels peuvent être aussi bien de l'IHM que de la manipulation d'images, du XML, etc... Le but de GObject c'est d'apporter les conventions pour que tout Gnome utilise la même 'façon de faire' la couche objet.

          Les benchs peuvent dans certains cas être intéressants, notamment pour tester la gestion de la mémoire (notamment BinaryTrees) ou la compréhension du code Vala, C# et C. La langage Vala en lui même n'apporte pas de chose en plus que du C/GObject bien codé. Ce langage permet surtout à des nouveaux programmeurs intéressées par GNOME d'éviter de mettre le nez dans du C qui suit des conventions pour apporter de l'objet.

          J'avoue certains benchs ne servent pas vraiment à grand chose sauf à l'appel de fonctions C :).
    • [^] # Re: langage de haut niveau?

      Posté par . Évalué à 3.

      Non: en D "par défaut" tu utilise un GC, mais en cas de besoin tu peux faire de l'allocation manuelle et utiliser des pointeurs..

      Les GC ne sont pas forcément le bon outil dans toutes les situations (même si par défaut c'est plus raisonnable d'utiliser un GC que de gerer soi-meme la mémoire).
      • [^] # Re: langage de haut niveau?

        Posté par . Évalué à -1.

        C'est marrant, j'aurais dit l'inverse : par défaut, il vaut mieux savoir désallouer ce que tu as alloué et en cas de besoin (l'allocation et la désallocation se font à des moments et des endroits bien distincts), on peut avoir recours à un GC.

        C'est quoi cette mode de mettre des GC partout ? Un GC n'est pas la réponse à tout, loin de là...
        • [^] # Re: langage de haut niveau?

          Posté par . Évalué à 5.

          l'idee sous jacente c'est qu'une machine est bien plus adaptee a la tache toute bete qui est le comptage des references qu'un etre humain.
          Et que ca enleve pas mal de bogues potentiels quand meme.
          Et ca fait des vacances au developpeur qui peut se concentrer sur son reel boulot (developer une appli, pas traquer des cases en memoire).
          • [^] # Re: langage de haut niveau?

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

            L'autre idée sous-jacente, c'est qu'un humain fera probablement toujours mieux son travail qu'un compteur de référence (l'humain sait libérer une liste doublement chaînée par exemple, alors que le comptage de référence non). Bon mais c'est juste un détail car l'humain est par ailleurs plus mauvais que les autres GC. :-)
            • [^] # Re: langage de haut niveau?

              Posté par . Évalué à 1.

              ah bon?
              Je te fait des listes doublement chainees, le GC de java le libere tres bien.

              En 4 ans de dev Java, j'ai jamais vu un GC se planter et liberer quand il ne fallait pas ou ne pas liberer quand il fallait.
              Des humains qui font ces 2 erreurs en C++, par contre, j'en ai vu quelques uns...

              Ah si, j'ai eu une fuite memoire en Java, une fois. Apres 15 jours de recherche, elle etait localisee dans la lib C++ appelee en JNI...
              • [^] # Re: langage de haut niveau?

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

                On dirait que tu dis la même chose que moi, en faisant semblant de dire le contraire. En effet c'est rassurant que tu n'aies pas trouvé de fuite dans la JVM, puisque justement il paraît qu'elle n'utilise pas de comptage de référence :-)
                http://java.sun.com/docs/hotspot/gc1.4.2/#4.%20Types%20of%20(...)

                Avec mon commentaire, je cherche juste à tordre le coup à l'opinion qui dit qu'un compteur de référence c'est la panacée. (Par ailleurs, les gens qui codent des compilateurs le savent, regardez par exemple pour Parrot : http://www.parrotcode.org/faq/#Why_aren't_you_using_referenc(...) ). Généralement, tout autre GC est préférable.

                Au passage, deux langages et pas des moindres se traînent ce handicap : Perl et Python... Et pour Perl, cela donne par exemple la méthode delete du paquet HTML::Element.
                http://search.cpan.org/~petek/HTML-Tree-3.23/lib/HTML/Elemen(...)
                • [^] # Re: langage de haut niveau?

                  Posté par . Évalué à 2.

                  ok, au temps pour moi, j'avais mal compris ton message, par "comptage de reference", je pensais que tu parlais des GC en general.
                • [^] # Re: langage de haut niveau?

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

                  Non, il y a depuis pas mal de temps me semble-t-il un GC dans Python.
                  D'ailleurs je me demande dans quelle mesure du comptage de référence pour faire le gros du boulot, plus un GC pour les cas problématiques, est une solution meilleure (ou moins bonne) qu'un GC tout seul....
                  • [^] # Re: langage de haut niveau?

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

                    Il y a eu des implémentations avec un GC optionnel mais la version standard fonctionne toujours par comptage de référence.

                    Dans pypy en revanche, le choix du GC est entièrement configurable. En fait, dans pypi, tout est configurable.
              • [^] # Re: langage de haut niveau?

                Posté par . Évalué à 2.

                >En 4 ans de dev Java, j'ai jamais vu un GC se planter et liberer quand il ne fallait pas ou ne pas liberer quand il fallait.

                Il ne fait jamais dire jamais :-) :
                en 99, j'ai eu un bug du GC de la JVM Sun qui libérait des objets quand il ne le fallait pas (il ne prenait pas en compte les references statiques).

                Assez pénible ce bug d'ailleurs car il induisait un plantage aléatoire de mon prog..
        • [^] # Re: langage de haut niveau?

          Posté par . Évalué à 4.

          C'est quoi cette mode de mettre des GC partout ? Un GC n'est pas la réponse à tout, loin de là...

          Non, mais c'est la plupart du temps une bonne réponse au problème de la gestion mémoire des objets alloués.

          par défaut, il vaut mieux savoir désallouer ce que tu as alloué

          La source de bugs en général ce n'est pas "comment désallouer" mais "quand désallouer"...
  • # compilo

    Posté par . Évalué à 4.


    Vala est un langage de programmation avec une syntaxe fortement inspirée du C# conçu pour l'environnement GNOME.

    Y aurait il la grammaire du langage quelque part ? L'API ?
    J'ai rien vu de précis sur le site de vala.

    Bien qu'il s'agisse d'un langage de haut niveau, possédant par exemple des patrons de classe, de l'inférence de type ou des fonctions anonymes, il est compilé en C et utilise la bibliothèque GObject de façon standard.
    Et qu'est ce que ça change ?
    A part que ça sent un peu l'usine à gaz derrière.
    J'espère qu'ils ont prévu des surcouche à gcc, gdb, ... pour retranslater le C généré en un truc débugable.

    Je trouve dommage qu'ils ne sont pas parti d'un langage existant. Créer un langage propre et qui marche est loin d'être trivial...

    Et pour la fin un petit troll tirer de http://live.gnome.org/Vala
    There won't be a vala runtime library and applications can distribute the generated C code with their tarballs, so there are no additional run- or build-time dependencies for users.
    miam, ca va être du bonheur s'il y a des erreurs de compil.
    • [^] # Re: compilo

      Posté par . Évalué à 4.

      Non, le code généré par Vala est très lisible et extrèmement proche de ce qu'aurait écrit un développeur C+GObject (certains argueront que ce n'est justement pas lisible, mais là n'est pas le troll :))

      > Et qu'est ce que ça change ?
      100% et immédiatement compatible avec le C et l'énorme paquet de code GObject existant, le tout avec une syntaxe un peu moins lourde

      > Créer un langage propre et qui marche est loin d'être trivial...
      Justement, c'est plus proche d'un préprocesseur que d'un vrai langage...
    • [^] # Re: compilo

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

      Si tu veux la grammaire du langage, regarde dans les exemples, ils sont relativement complets et permettent de commencer à programmer en Vala très simplement. De plus si tu connait le C#, tu connait le Vala.

      Pour 'l'usine à gaz' tu repassera, tout les constructions syntaxiques de Vala sont formalisés dans GObject. Ceci permet de ne pas rajouter de surcoût par rapport à du C/Gnome bien programmé. L'option '-g' du compilateur valac permet d'ajouter les '#line ' qui vont bien dans le fichier C généré et permettent à gdb de retrouver ses petits dans le fichier .vala correspondant.

      Le langage existant s'appelle le C# et je pense qu'il est suffisamment connu et reconnu pour être considéré comme MAJEUR. Le fait de ne pas avoir eu à spécifier la grammaire du langage permet de rassembler les programmeurs. La réponse de Jürg (le développeur principal) à tout ajout de syntax est clair, ce qui n'est pas utilisé pour du C#, ne doit pas l'être pour du Vala (j'ai perdu le lien).
      • [^] # Re: compilo

        Posté par . Évalué à 5.

        La réponse de Jürg (le développeur principal) à tout ajout de syntax est clair, ce qui n'est pas utilisé pour du C#, ne doit pas l'être pour du Vala (j'ai perdu le lien).

        Voilà qui promet une grande évolutivité :-))
        • [^] # Re: compilo

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

          j'aurais peut-être du dire ça autrement :).

          Le fait de transformer la syntaxe pour mieux coller au modèle GObject a déjà été effectuée (l'exemple du construct). Seulement un changement/ajout majeur de syntaxe ne peut que porter à confusion et ce n'est pas le but du langage de définir une nouvelle syntaxe.

          Je dois être plus clair comme ça :). Et pour l'évolution du langage tu peut toujours contacter Jürg sur [irc://irc.gimp.org/#vala], je pense qu'il saura mieux t'expliquer que moi ;).
    • [^] # Re: compilo

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

      Le c# est un normé ECMA (javascript aussi)
      http://www.ecma-international.org/publications/standards/Ecm(...)


      C'est juste du "sucre syntaxique" pour que les humains puissent écrire dans le CLR (common language runtime)

      le c#/VBscript est au CLR ce que perl 6.0 et python seront à parrot (si ça arrive un jour) juste un truc haut niveau agréable à lire et à écrire.

      En fait si on fait un parser/analyseur lexical on peut avec la norme faire un transformateur c# -> python/perl ou autres, mais faut être maso : faire des closures et proche de l'impossible en c# (voir delegate et lambda function)

      Les trucs intéressants sont les generics et les delegates.

      A noter que comme leur truc étaient trop rigide (typage fort) ils ont le DLR (dynamic language runtime) avec comme portage : javascript coté serveur / python qui pondent du CLR au final bindable avec avec les dll systèmes et vice versa.
  • # Vala

    Posté par . Évalué à 10.

    C'est fait.
  • # et le langage D alors

    Posté par . Évalué à 5.

    Ils auraient mieux fait de partir d'un langage qui a mon avis va sortir de sa niche dans les années à venir et qui est le langage D. Pour ceux qui ne connaissent pas il s'agit d'un langage décrit par les créateurs comme le descendant du C++ avec une syntaxe s'approchant de Java.
    Le code généré est natif mais et possède un garbage-collector.
    L'avantage est que le compilateur est un front-end à gcc et qu'il peut donc être disponible sur un grand nombre de plate formes.
    • [^] # Re: et le langage D alors

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

      Le langage est encore jeune, il faut voir comment il évolue et comment il sera suivi, ceci dit, je garde un œil dessus. Il y a déjà des bindings intéressants (wxWidget par exemple), et il y a déjà 2 compilateurs (dmd, celui de Digital Mars, la société créatrice, et gdc, frontend à gcc). On peut compiler du D sur Mac OSX, Linux, et MS Windows.

      Pour plus d'informations, en vrac :
      http://fr.wikipedia.org/wiki/D_(langage)
      http://www.digitalmars.com/d/dcompiler.html
      http://dgcc.sourceforge.net/
    • [^] # Re: et le langage D alors

      Posté par . Évalué à 6.

      Bon, on va répéter pour ceux au fond qui n'ont pas écoutés:
      Le but est (entre autre) d'être directement et nativement compatible au niveau ABI (et quasi immédiatement au niveau API) avec GObject (c'est un projet Gnome, après tout), même pour le modèle objet. Tu peux m'expliquer comment tu fais ça avec D ? L'ABI de D est très proches de celle du C++, et n'a rien à voir avec celle de Vala/GObject qui est du pur C.

      Pour faire encore plus clair, supposons que je fasse en Vala puis en C++ ou en D une classe Foo avec une méthode bar. Maintenant, je veux appeler cette méthode dans un programme C (disons, pour simplifier, que j'ai déjà une instance f). Si ça a été codé en vala:
      foo_bar(FOO(f)); (fonctionne de la même manière que gtk_window_set_title(GTK_WINDOW(w), "Hello, world"); )
      en C++:
      _ZN3Foo3barEv(f); (je ne l'ai pas inventé, c'est le nom qu'a donné G++ à la méthode...)
      Et encore, ce code dépend de l'ABI C++ du compilateur, et j'ai considéré que la fonction n'était pas virtuelle. Vois tu où se situe Vala, maintenant ?

      Pour rentrer dans le troll, j'avais regardé du côté de D il y a quelques années lorsqu'il venait à peine d'être libéré, et c'était à l'époque assez intéressant. Mais maintenant qu'aujourd'hui on a GCJ, j'ai du mal à voir l'intérêt.

      > L'avantage est que le compilateur est un front-end à gcc et qu'il peut donc être disponible sur un grand nombre de plate formes.
      Vala transformant en code C pour le faire avaler à GCC, je pense qu'on peut difficilement faire plus portable :)
      • [^] # Re: et le langage D alors

        Posté par . Évalué à 3.

        Pour faire encore plus clair, supposons que je fasse en Vala puis en C++ ou en D une classe Foo avec une méthode bar. Maintenant, je veux appeler cette méthode dans un programme C

        La vraie question, c'est de savoir à quoi ça sert.

        Si Vala (resp. C++) permet de programmer plus sûrement et plus rapidement qu'en C, et qu'il génère du code rapide et compact comme du C, alors il n'y a aucun intérêt à appeler une méthode Vala (resp. C++) depuis du code C plutôt que de directement faire du Vala (resp. C++).

        C'est exactement ce qui se passe pour KDE : en pratique tout le monde se fout que les kdelibs ne soient pas facilement invocables en C. Faire du C/gobject plutôt que n'importe quel langage orienté objet dès l'origine, faut être sérieusement maso.
        • [^] # Re: et le langage D alors

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

          l'intérêt est par exemple de pouvoir créer facilement un plugin pour un programme C qui ne supporte pas de binding pour son interface de plugin par exemple. Le tout en utilisant un langage haut niveau.
          • [^] # Re: et le langage D alors

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

            Là tu parles du fait qu'on puisse utiliser des fonctions C dans un code en Vala.

            Or, ce dont Moonz et Antoine parlaient c'est l'inverse : utiliser des fonctions Vala dans un programme en C.
        • [^] # Re: et le langage D alors

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

          Et pour faire du C++, il faut aussi être sérieusement maso.
    • [^] # Re: et le langage D alors

      Posté par . Évalué à 1.

      sorry, mais moi, on me dis syntaxe java, je fuis !

      (ma memoire aussi, mais ça c'est une autre histoire...)
      • [^] # Re: et le langage D alors

        Posté par . Évalué à 2.

        Vala a une syntaxe C#-like, ce qui n'est pas très loin d'une syntaxe Java-like...
      • [^] # Re: et le langage D alors

        Posté par . Évalué à -1.

        Ha alors on va dire qu'il a une syntaxe proche du C/C++.
        Ça te plaît plus peut être plus?
        • [^] # Re: et le langage D alors

          Posté par . Évalué à 1.

          c'est etrange, mais personnelement, je ne trouve pas la syntaxe java et la syntaxe C++ tres proche... ok, pour les objet, ça se resemble, ok, mais en C++, j'ai pas besoin de faire librarie.math.float.sqrt pour avoir une racine carré !

          bon, ok, après, il parais que les IDE moderne corrige ça de manière souple et agréable.
          • [^] # Re: et le langage D alors

            Posté par . Évalué à 1.

            La syntaxe java a pas grand chose a voir avec l'appel a la fonction Math.sqrt.

            Cela dit, en c++, tu feras un std::sqrt, ca se ressemble beaucoup quand meme, hein...
    • [^] # Re: et le langage D alors

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

      Ah oui, c'est vrai, le langage D, on l'avait oublié suila : http://linuxfr.org/comments/399822.html#399822

      « J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »

Suivre le flux des commentaires

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