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.
Aller plus loin
- Vala - GNOME Live! (6 clics)
- [ANNOUNCE] Vala 0.1.6 (1 clic)
- Journal : Un langage pas comme les autres : Vala (13 clics)
# C & Cie
Posté par moramarth . Évalué à 7.
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 Hal9000 . Évalué à 3.
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 Anonyme . Évalué à 10.
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 Jack ze . Évalué à -5.
[^] # Re: C & Cie
Posté par Vivi (site web personnel) . Évalué à 5.
ben non justement, ça génère du C.
[^] # Re: C & Cie
Posté par Ben (site web personnel) . Évalué à 1.
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. -- Jules Claretie
[^] # Re: C & Cie
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Au moins du ELF, non ?
[^] # Re: C & Cie
Posté par Antoine . Évalué à 1.
[^] # Re: C & Cie
Posté par mickabouille . Évalué à 2.
[^] # Re: C & Cie
Posté par HoloAddict (site web personnel) . Évalué à 2.
C'est donc juste un nom par défaut, et plus un format d'éxécutable.
[^] # Re: C & Cie
Posté par Antoine . Évalué à 1.
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 Émilien Tlapale . Évalué à 1.
http://en.wikipedia.org/wiki/A.out
[^] # Re: C & Cie
Posté par Larry Cow . Évalué à 2.
[^] # Re: C & Cie
Posté par Moonz . Évalué à 10.
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 Florent Morin . Évalué à 2.
[^] # Re: C & Cie
Posté par Moonz . Évalué à 6.
[^] # Re: C & Cie
Posté par Émilien Tlapale . Évalué à 3.
[^] # Re: C & Cie
Posté par Gof (site web personnel) . Évalué à 4.
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 Philippe F (site web personnel) . Évalué à 5.
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 Émilien Tlapale . Évalué à 2.
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 Antoine . Évalué à 3.
Au fait, il est capable de casser les cycles de références ?
[^] # Re: C & Cie
Posté par Vivi (site web personnel) . Évalué à 1.
[^] # Re: C & Cie
Posté par Gof (site web personnel) . Évalué à 2.
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 Étienne . Évalué à 5.
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 CrEv (site web personnel) . Évalué à 4.
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 Étienne . Évalué à 5.
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 CrEv (site web personnel) . Évalué à 2.
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 Étienne . Évalué à 3.
C'est à dire ?
[^] # Re: C & Cie
Posté par CrEv (site web personnel) . Évalué à 2.
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 Étienne . Évalué à 1.
Comme à peu près tous les langage, Objective-C, Java, C# et autres compris.
[^] # Re: C & Cie
Posté par el_mickey . Évalué à 1.
[^] # Re: C & Cie
Posté par Aldoo . Évalué à 2.
[^] # Re: C & Cie
Posté par jcs (site web personnel) . Évalué à 2.
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 Aldoo . Évalué à 1.
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 Étienne . Évalué à 2.
[^] # Re: C & Cie
Posté par zul (site web personnel) . Évalué à 3.
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 el_mickey . Évalué à 0.
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 zul (site web personnel) . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 zul (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 1.
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 mats . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 1.
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 mats . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 2.
[^] # Re: C & Cie
Posté par Étienne . Évalué à 2.
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
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 CrEv (site web personnel) . Évalué à 4.
"logiquement" dans un modèle objet, on ferait :
Dans ton cas on a tout simplement une _fonction_ sort qui prend un container...
[^] # Re: C & Cie
Posté par Étienne . Évalué à 3.
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 pw00t . Évalué à 1.
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 Étienne . Évalué à 3.
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 pw00t . Évalué à 1.
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 letsyl . Évalué à 3.
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 zul (site web personnel) . Évalué à 2.
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 Étienne . Évalué à 2.
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 pw00t . Évalué à 0.
[^] # Re: C & Cie
Posté par letsyl . Évalué à 1.
Ce n'est donc pas du tout la même chose que d'avoir maCollection.sort()
[^] # Re: C & Cie
Posté par pw00t . Évalué à 0.
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 zul (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 1.
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 beagf (site web personnel) . Évalué à 2.
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 pw00t . Évalué à 1.
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 CrEv (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 2.
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 Thomas Douillard . Évalué à 3.
[^] # Re: C & Cie
Posté par CrEv (site web personnel) . Évalué à 2.
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 Étienne . Évalué à 3.
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 CrEv (site web personnel) . Évalué à 0.
C'est bien là le "problème"...
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 khivapia . Évalué à 2.
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 Étienne . Évalué à 3.
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 :
Pour trier on va alors faire
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 khivapia . Évalué à 2.
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 Étienne . Évalué à 3.
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 Philippe F (site web personnel) . Évalué à 5.
- 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 Étienne . Évalué à 2.
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 benoar . Évalué à 2.
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 Philippe F (site web personnel) . Évalué à 6.
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 Étienne . Évalué à 2.
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 GeneralZod . Évalué à 2.
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 Antoine . Évalué à 1.
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 Moonz . Évalué à 3.
Tu veux dire, comme avec std::fstream ? :)
[^] # Re: C & Cie
Posté par Étienne . Évalué à 2.
J'avoue que j'ignore ce qui justifie qu'on n'ai qu'un constructeur prenant un "const char*".
[^] # Re: C & Cie
Posté par Moonz . Évalué à 2.
Haem...
http://cplusplus.com/reference/iostream/istream/getline.html
http://cplusplus.com/reference/iostream/streambuf/xsgetn.htm(...)
[^] # Re: C & Cie
Posté par Étienne . Évalué à 2.
Pour xsgetn, on parle là d'une fonction sur les streambuf, qui a en charge de lire et d'ecrire les fichiers textes. Le char* du xsgetn n'est pas une chaine de charactères au sens C du terme, c'est juste un buffer (non terminé par un 0 par exemple).
[^] # Re: C & Cie
Posté par Sebastien Binet . Évalué à 1.
Rien, a part la compatibilite avec des bibliotheques C.
Mais ca devrait etre rectifie avec C++09:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n190(...)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n236(...)
(PDF de 8Mb...)
[^] # Re: C & Cie
Posté par Troy McClure (site web personnel) . Évalué à 4.
[^] # Re: C & Cie
Posté par Étienne . Évalué à 3.
[^] # Re: C & Cie
Posté par Sébastien B. . Évalué à 9.
Tiens c'est marrant ça, moi j'en vois 4 de trop.
[^] # Re: C & Cie
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
# langage de haut niveau?
Posté par mickabouille . Évalué à 6.
[^] # Re: langage de haut niveau?
Posté par ciol . Évalué à 0.
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 Clément David (site web personnel) . Évalué à 3.
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 Antoine . Évalué à 1.
C'est ça les "TreeNode#" dans ton programme ?
[^] # Re: langage de haut niveau?
Posté par Clément David (site web personnel) . Évalué à 1.
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 M . Évalué à 3.
[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 Clément David (site web personnel) . Évalué à 4.
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 reno . Évalué à 3.
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 rewind (Mastodon) . Évalué à -1.
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 pw00t . Évalué à 5.
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 Florian Hatat . Évalué à 1.
[^] # Re: langage de haut niveau?
Posté par pw00t . Évalué à 1.
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 Florian Hatat . Évalué à 2.
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 pw00t . Évalué à 2.
[^] # Re: langage de haut niveau?
Posté par GuieA_7 (site web personnel) . Évalué à 1.
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 Philippe F (site web personnel) . Évalué à 2.
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 reno . Évalué à 2.
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 pw00t . Évalué à 2.
ya pire quand meme :p
[^] # Re: langage de haut niveau?
Posté par Antoine . Évalué à 4.
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 M . É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 Moonz . Évalué à 4.
> 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 Clément David (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 5.
Voilà qui promet une grande évolutivité :-))
[^] # Re: compilo
Posté par Clément David (site web personnel) . Évalué à 2.
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 Jul (site web personnel) . Évalué à 3.
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 Hojo . Évalué à 10.
[^] # Re: Vala
Posté par Bozo_le_clown . Évalué à 8.
[^] # Re: Vala
Posté par shbrol . Évalué à 5.
[^] # Re: Vala
Posté par satan . Évalué à -1.
# et le langage D alors
Posté par mosfet . Évalué à 5.
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 Michel Petit (site web personnel) . Évalué à 4.
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 Moonz . Évalué à 6.
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 Antoine . Évalué à 3.
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 Bapt (site web personnel) . Évalué à 1.
[^] # Re: et le langage D alors
Posté par Gof (site web personnel) . Évalué à 1.
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 Bapt (site web personnel) . Évalué à 3.
[^] # Re: et le langage D alors
Posté par Mildred (site web personnel) . Évalué à -3.
[^] # Re: et le langage D alors
Posté par Charles-Victor DUCOLLET . Évalué à 1.
(ma memoire aussi, mais ça c'est une autre histoire...)
[^] # Re: et le langage D alors
Posté par Antoine . Évalué à 2.
[^] # Re: et le langage D alors
Posté par mosfet . Évalué à -1.
Ça te plaît plus peut être plus?
[^] # Re: et le langage D alors
Posté par Charles-Victor DUCOLLET . Évalué à 1.
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 pw00t . Évalué à 1.
Cela dit, en c++, tu feras un std::sqrt, ca se ressemble beaucoup quand meme, hein...
[^] # Re: et le langage D alors
Posté par Christophe Duparquet (site web personnel) . Évalué à 2.
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.