vendredi 05 février

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

Site officiel (1557 clics)
Téléchargement (120 clics)
Guide de Référence (296 clics)
Le dépot git (104 clics)

Dépêche modérée par

Nyco

Dépêche éditée par

Articles : Le language de programmation ooc sorti en version 0.2

Posté par Amos Wenger (Jabber id, page perso, ). Modéré le 26 juin 2009.

Aujourd'hui est sorti la version 0.2 du langage de programmation ooc.

ooc est un langage de programmation libre, orienté objet, compilé, et portable. Il se veut léger, rapide, pratique et surtout libre !

Un des buts d'ooc est de combiner les avantages de langages de haut niveau comme Java ou C# avec la rapidité du C. Pour ce faire, les fichiers sources .ooc sont traduits en C, puis compilés avec GCC, ICC (Intel), ou n'importe quel compilateur C99.

ooc est orienté objet, profite du ramasse-miettes conservatif Boehm (garbage collector), organise les classes en paquetages, gère automatiquement les dépendances et toutes les bibliothèques C sont utilisables nativement.

Site officiel (1557 clics)
Téléchargement (120 clics)
Guide de Référence (296 clics)
Le dépot git (104 clics)

> Lire la suite (173 commentaires, moyenne: 2). [dépêche : 1096 caractères]

Malgré la jeunesse relative du langage (5 mois) et de son compilateur, il est déjà très utilisable. Son SDK (bibliothèque standard) contient quelques classes pour les entrées/sorties, la manipulation de chaîne de caractères, la gestion du temps, etc.

L'implémentation de référence du compilateur est codée en Java, donc il est assez portable. Cependant, des binaires sont construits pour Linux et Windows avec GCJ (le compilateur Java de la famille GNU), donc il n'y a pas besoin du JRE pour faire fonctionner le compilateur. En outre, les programmes produits sont en C99 pur, ils ne nécessitent donc pas Java du tout.

La version 0.2 du langage et de son compilateur introduisent les changements suivants :

Une syntaxe plus claire et lisible ;
Beaucoup de corrections de bugs ;
De meilleurs bindings GTK/SDL/OpenGL/GLU/GLUT ;
Une meilleure compatibilité Windows (MinGW) ;
Désormais distribué sous forme binaire pour Linux et Windows ;
Pour plus d'informations, voir le journal des modifications sur GitHub.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Hmmm

Posté par dest () le 26/06/2009 à 14:59. (lien). Évalué à 3.

En gros, c'est une surcouche haut niveau du C. Un peu comme OCAML sauf qu'OCAML est un langage formel et ça, ça apporte vraiment de la sécurité pour développer nos applications et éviter d'avoir des trous partout.

C'est pas pour rien qu'on parle de plus en plus d'approches formelles.

De plus OCAML dispose d'un garbage collector très puissant, c'est objet, y'a des exceptions, c'est fortement typé, pas de buffer overflow,... (liste non exhaustive).

Bref ooc d'après ta description ne me rassure pas sur les buffer overflow, les cast, les pointeurs. Plein de sources à trous.

[^]Re: Hmmm

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 15:12. (lien). Évalué à 4.
Très juste. Mais il faut bien commencer quelque part, non ?

Il est vrai que pour l'instant, la "sécurité" n'a pas ete un objectif prédominant dans l'implémentation. Cependant, rien dans le design du langage/du compilateur ne s'oppose a l'intégration de mécanismes de contrôle tel qu'on peut trouver dans OCaml, par exemple.

Malheureusement la sécurité a un coût performance, c'est pour ça que je pense laisse l'option de désactiver les (futurs) mécanismes de sécurité/vérification dans les prochaines versions. (Exemple: activé pendant le développement/débuggage, désactivé en environnement ou la performance est critique)

Après, il faut garder a l'esprit qu'aucun langage n'est la réponse définitive a tous les besoins. Quant a coder "sécurisé", pourquoi ne pas choisir Ada?

En résumé, pour continuer la série des métaphores, je dirais que: "ooc still allows you to shoot yourself in the foot, but with a cooler weapon" ;)
- [^]Re: Hmmm
  
  Posté par dest () le 26/06/2009 à 15:48. (lien). Évalué à 4.
  Je trouve ça très dangereux de privilégier les performances à la sécurité.
  OCaml est sécurisé et s'exécute presqu'aussi vite que du C.
  
  Après les performances sont nécessaires si tu fais du calcul très lourd comme en crypto mais de nos jours, avec la puissance dont nos machines disposent, il faut d'abord miser sur la sécurité avant de penser aux performances.
  - [^]Re: Hmmm
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 15:54. (lien). Évalué à 4.
    Ma foi, le monde est un endroit bien dangereux. La sécurité implique toujours un coût, et "presque aussi vite que du C" n'est pas vraiment une mesure objective. Je serais assez intéressé par une série de benchmarks C vs Objective-C aussi peu biaisés que possible.
    - [^]Re: Hmmm
      
      Posté par oops (page perso, ) le 26/06/2009 à 17:41. (lien). Évalué à 2.
      Je serais assez intéressé par une série de benchmarks C vs Objective-C aussi peu biaisés que possible.
      
      Avec ObjC, tu peux mélanger du C et de l'ObjC. Ce qui est interessant pour les parties à optimiser.
      
      Sinon pour les appels de fonctions/méthodes/messages j'avais vu passer des benchs sur une liste GNUstep (la personne qui avait posté s'appelé Alexender Malmberg) mais je ne retrouve plus le post.
      
      En gros pour ces appels :
      1-ObjC avec IMP-caching
      2-C
      3- appel ObjC "standard"
      - [^]Re: Hmmm
        
        Posté par Nicolas Roard (page perso, ) le 30/06/2009 à 03:05. (lien). Évalué à 1.
        Pas tout a fait les memes mesures, mais je m'etait amuse a faire joujou avec les perfs ObjC y'a quelques temps...
        
        http://camaelon.blogspot.com/2007/01/fun-with-objective-c.ht(...)
        
        Note qu'en pratique, la seule fois ou j'ai fait du IMP-caching c'etait sur un algo de rendu volumetrique qui devait aller aussi vite que possible (pour avoir du rendu interactif reparti), et encore c'etait loin d'avoir ete LE facteur determinant au niveau rapidite...
        
        Pour un logiciel 'normal' y'a franchement peu d'interet de nos jours je trouve. Maintenant bon, ce qu'il y a de bien c'est qu'on peut toujours le faire si vraiment on veut ;-)
    - [^]Re: Hmmm
      
      Posté par Barret Michel (Jabber id, page perso, ) le 27/06/2009 à 14:37. (lien). Évalué à 1.
      C'est pas forcément vraie. Le C++ peut être plus rapide que le C par exemple parce qu'il a un typage un peu plus fort (il y a d'autre raison dont les optimisation grâce à l'approche objet etc).
      
      --
      Debian Sid
      - [^]Re: Hmmm
        
        Posté par Nicolas Boulay () le 28/06/2009 à 13:18. (lien). Évalué à 2.
        Dans les micro bench, c++ est plus rapide grâce au template programming.
        
        --
        "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
  - [^]Re: Hmmm
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 16:01. (lien). Évalué à 1.
    Ceci dit, je retiens le commentaire et c'est effectivement une des choses a améliorer avant ooc 0.3
    
    Pour les intéressés, voici le rapport de bug correspondant: [https://bugs.launchpad.net/ooc-language/+bug/392551]
- [^]Re: Hmmm
  
  Posté par chicco () le 26/06/2009 à 15:49. (lien). Évalué à 5.
  Quitte à utiliser un langage surcouche de C, autant en utiliser un bon:
  Je ne sais pas si vous connaissez ATS (Applied Type System), ça a presque toutes les bonnes propriétés du Caml: typage statique, garbage collector, efficace, fonctions de première classe, etc.
  Mais en plus il y a plein d'autres choses vraiment bien:
  - types linéaires et types dépendants
  - possibilité de gérer sa mémoire à la main, mais de manière sûre. C'est à dire que si l'on ne veut pas du coût supplémentaire introduit parfois par le GC, on peut faire ses mallocs à la mains, mais il faut que le code reste bien typé ( ce sont les types linéaires qui gèrent ça: il est imposible de faire une segfault )
  - les fonctions C sont typables ( on doit ajouter des annotations de type bien sûr ). Il est donc possible d'appeler des fonctions C sans avoir à écrire de binding.
  
  Bon il y a forcément quelques petits problèmes, déjà, contrairement au Caml, les types ne sont pas complètement inférables, il faut donc annoter les fonctions. En pratique ce n'est pas un problème car quand on code une fonction, on sait toujours quel type elle devrait avoir.
  Le compilateur est un peu jeune ( c'est un projet de recherche ), et ça manque un peu de finition ( les erreurs de type ne sont pas toujours facile à comprendre par exemple ).
  Ça manque aussi d'un toplevel.
  Et c'est peut être un peu difficile au début de comprendre à quoi correspondent tous les types.
  
  Et ne me dites pas "oui mais il n'y a pas d'objets". Le système de type est largement assez puissant pour faire tout ce qu'on pourrait vouloir faire avec des objets.
  
  Pour se faire une idée: [http://www.ats-lang.org/TUTORIAL/tutorial.html]
- [^]Re: Hmmm
  
  Posté par Jérémie Dimino () le 26/06/2009 à 17:52. (lien). Évalué à 4.
  Je pense que tu parles de la sécurité par des tests durant l'exécution. Ce qui permet juste d'avoir des vrai erreurs plutôt que des segfaults.
  
  La sécurité en ocaml est assuré par du typage 'statique'. Il n'y a donc aucun impact sur les performances vu que tout est vérifié au moment de la compilation. En fait c'est même le contraire, vu que le compilateur connaît plus de truc sur le code il est capable de faire plus d'optimisations qu'un compilateur C.
  - [^]Re: Hmmm
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 18:08. (lien). Évalué à 2.
    C'est effectivement de ça que je parlais.
    
    Pour ce qui est du typage, ooc est déjà sensiblement plus malin/contraignant qu'un simple compilateur C. Si on déclare les variables avec le bon type, le compilateur vérifie tous les appels fonctions et accès aux champs.
    
    La seule manière de contourner cette sécurité est de faire un méchant cast (seuls les casts ne sont pas vérifiés). Donc en gros, le programmeur a potentiellement les problèmes qu'il mérite / est puni selon les risques qu'il prend.
  - [^]Re: Hmmm
    
    Posté par JoeltheLion (page perso, ) le 26/06/2009 à 21:17. (lien). Évalué à 6.
    
    La sécurité en ocaml est assuré par du typage 'statique'. Il n'y a donc aucun impact sur les performances vu que tout est vérifié au moment de la compilation. En fait c'est même le contraire, vu que le compilateur connaît plus de truc sur le code il est capable de faire plus d'optimisations qu'un compilateur C.
    
    Je rappelle qu'en pratique, le code Ocaml s'execute environ 2 fois moins vite que du code en C ou en C++
    
    http://shootout.alioth.debian.org/u64q/benchmark.php?test=al(...)
    
    On peut critiquer le benchmark tout ce qu'on veut, il reflète en général bien la réalité.
    
    --
    (pub: Autojump : une manière plus rapide de naviguer dans le système de fichiers avec la ligne de commande)

[^]Re: Hmmm

Posté par Nicolas Boulay () le 28/06/2009 à 13:16. (lien). Évalué à 3.
C'est quoi la définition exacte de "formelle" pour un langage ?

--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
- [^]Re: Hmmm
  
  Posté par auve () le 28/06/2009 à 15:40. (lien). Évalué à 1.
  La mauvaise, ie. pas celle là : http://en.wikipedia.org/wiki/Formal_language
  
  --
  « Puissance de l'absorbtion méditative. » -- Samten Wangchen
  - [^]Re: Hmmm
    
    Posté par Nicolas Boulay () le 29/06/2009 à 11:03. (lien). Évalué à 2.
    Cela ne m'avance pas :)
    
    En quoi C, même totalement tordu, n'est pas complètement défini ?
    
    --
    "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
    - [^]Re: Hmmm
      
      Posté par reno () le 29/06/2009 à 13:09. (lien). Évalué à 1.
      Mmm: si tu fais un accès a un tableau avec un index invalide en C le comportement que tu as est indéfini.
      Il doit y en avoir d'autre..
      - [^]Re: Hmmm
        
        Posté par Nicolas Boulay () le 29/06/2009 à 14:27. (lien). Évalué à 2.
        Formel dans ce sens là, ok.
        
        Dans les faits, tu as sois une access violation, soit d'anciennes données, soit des données d'autres structures.
        
        Donc, formel veut dire que tout les cas sont spécifiés, qu'il n'y aucun comportement user defined, ou aléatoire ou dépendant de l'implémentation .
        
        --
        "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
        
        [^]Re: Hmmm
        
        Posté par auve () le 02/07/2009 à 21:39. (lien). Évalué à 1.
        Non, l'adjectif « formel » pour un langage le rattache à la... théorie des langages formels, c'est à dire des histoires d'automates, grammaires, complexité & tutti-quanti. Pas grand chose à voir a priori avec les langages de programmation usuelle, si ce n'est en ce qui concerne leur syntaxe.
        
        Par contre, dire qu'un langage de programmation a une sémantique formelle, ça veut dire que tu peux trouver quelque-part une description mathématique, i.e. précise et claire, de son comportement, que toutes les implantations sont sensées respecter. Ça a malheureusement été le cas de très peu de langages de programmation ; citons pour les plus connus Algol 60 et Standard ML, ou encore un certain Esterel (;-)).
        
        Pour en revenir à OCaml, malheureusement il n'a pas de sémantique formelle complète écrite quelque-part ; par contre, les diverses fonctionnalités spécifiques et innovantes du langage (la partie objet, les variantes polymorphe, sa machine abstraite, son système de modules...) sont décrites formellement dans les publications associées.
        
        --
        « Puissance de l'absorbtion méditative. » -- Samten Wangchen
        
        [^]Re: Hmmm
        
        Posté par Nicolas Boulay () le 03/07/2009 à 00:18. (lien). Évalué à 2.
        Esterel est moribond mais il reste encore Scade :)
        
        --
        "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
        
        [^]Re: Hmmm
        
        Posté par Vivi (page perso, ) le 03/07/2009 à 13:55. (lien). Évalué à 1.
        citons pour les plus connus Algol 60 et Standard ML
        
        et Scheme
        
        [^]Re: Hmmm
        
        Posté par reno () le 04/07/2009 à 22:01. (lien). Évalué à 2.
        Bien dit, cependant mon point avec le C est que, ayant une sémantique non défini dans certains cas, il ne peut pas être dans la liste des langages avec une sémantique formelle..
        
        Je ne suis pas certain d'avoir raison..

[^]Re: Hmmm

Posté par Vivi (page perso, ) le 28/06/2009 à 18:48. (lien). Évalué à 1.
En gros, c'est une surcouche haut niveau du C. Un peu comme OCAML sauf ...

sauf qu'OCaml n'est pas une surcouche du C !

ObjectiveC

Posté par Kasp () le 26/06/2009 à 15:09. (lien). Évalué à 3.

Quelles sont les différences entre ce projet et ObjectiveC ?

Simple curiosité.

[^]Re: ObjectiveC

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 15:32. (lien). Évalué à 2.
N'ayant pas réellement testé Objective-C ces derniers temps j'ai justement comparé un peu avec ooc en se basant sur la page Wikipédia d'[[Objective-C]]. On peut tout de même dire que les deux langages ont un public cible qui se ressemble.

Voici les quelques différences qui me sautent aux yeux:
- Objective-C utilise l'envoi de messages au lieu de l'appel de méthode
- Objective-C est un sur-ensemble strict du C, donc il hérite de ses bizarreries syntaxiques.
- Objective-C met l'accent sur les décisions au temps de l'execution, alors qu'ooc essaie d'attraper les erreurs au temps de la compilation.
- Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.

Enfin, ooc est inspiré en partie de Java, lui-meme inspire (entre autres) d'Objective-C, lui-meme inspire de Smalltalk. Concrètement, Objective-C est un langage mature qui apparamment ne changera plus beaucoup. Cela permet une grande stabilité, mais le langage est condamné a rester dans ses habitudes: il est trop tard pour tirer les leçons du passé (par exemple, gcc semble ne pas supporter totalement ObjC 2.0). Par contraste, ooc est un jeune galopin qui essaie d'apprendre de ses grands-parents. Il est largement encore temps de s'impliquer et d'influer sur le design.
- [^]Re: ObjectiveC
  
  Posté par Damien Cassou () le 26/06/2009 à 16:02. (lien). Évalué à 4.
  - Objective-C utilise l'envoi de messages au lieu de l'appel de méthode
  
  Pour moi «envoi de message» signifie juste que tu vas choisir la méthode à appeler (son implémentation) au moment de l'exécution et pas de la compilation. Quand tu fais de l'objet, je ne vois pas bien comment tu pourrais faire autrement : tu choisis la méthode en fonction du type dynamique de ton objet que tu ne connais pas, par définition, au moment de la compilation. Tu as une autre définition qui te permet de dire que vous avez 2 approches différentes ?
  
  --
  Damien Cassou
  - [^]Re: ObjectiveC
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 16:17. (lien). Évalué à 1.
    Je ne sais pas comment est implémenté le passage de messages en Objective-C, mais je sais que certains langages ont un algorithme de recherche de la méthode a appeler (en fonction des arguments et du type). En ce qui concerne ooc, l'appel d'une fonction membre implique seulement deux déréférencements de pointeurs, donc c'est relativement peu coûteux.
    - [^]Re: ObjectiveC
      
      Posté par Damien Cassou () le 26/06/2009 à 17:19. (lien). Évalué à 2.
      Je ne sais pas comment est implémenté le passage de messages en Objective-C, mais je sais que certains langages ont un algorithme de recherche de la méthode a appeler (en fonction des arguments et du type). En ce qui concerne ooc, l'appel d'une fonction membre implique seulement deux déréférencements de pointeurs, donc c'est relativement peu coûteux.
      
      Je dois manquer quelque chose. Dans l'exemple suivant:
      
      class Wheel { func roll {printf("Quelque-chose ne tourne pas rond.\n");} } class BetterWheel from Wheel { override roll {printf("Pierre qui roule n'amasse pas mousse\n");} } func main { BetterWheel bw = new; Wheel w2 = (Wheel) bw; // cast as in C/Java w2.roll; // prints "Pierre qui roule", etc. }
      
      Lors de la compilation de w2.roll, tu associes l'appel à roll à la méthode roll de Wheel (le type statique de w2). Lors de l'exécution, il te faut exécuter la méthode roll de BetterWheel et pas celle de Wheel.
      
      Le principe de base étant de partir de la classe dynamique de l'objet pour remonter la chaîne d'héritage jusqu'à tomber sur une implémentation de la méthode appelée.
      
      C'est pas ça que tu fais ?
      
      --
      Damien Cassou
      - [^]Re: ObjectiveC
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 17:43. (lien). Évalué à 1.
        Non. Tout est implémenté (pour l'instant) avec des pointeurs sur des fonctions. Donc, quand tu construis le premier objet Wheel, il est assigné au champ "roll" dans sa structure de classe l'adresse de la fonction roll tel qu'implémenté dans Wheel.
        Quand tu construis le premier objet BetterWheel, il est assigné au champ "roll" dans sa structure de class l'adresse de la fonction roll tel qu'implémenté dans BetterWheel. Ainsi, quand w2.roll est traduit par le compilateur en w2->_class->_roll() cela référence la bonne version.
        L'assignation des pointeurs de méthodes dans les structures de classes n'est faite qu'une seule fois par classe, et toutes les structures d'objet pointent vers la meme structure de classe, donc il n'y a quasiment aucun gaspillage mémoire ni CPU.
        
        [^]Re: ObjectiveC
        
        Posté par Damien (page perso, ) le 27/06/2009 à 21:06. (lien). Évalué à 2.
        il n'y a quasiment aucun gaspillage mémoire
        
        Si, parce que si tu as 100 méthodes dans une superclasse A, et une redéfinition dans sa sous-classe B, alors la table de lookup de B contient 101 entrées dont 100 redondantes.
        
        Le lookup récursif marche très bien et s'optimise avec les polymorphic inline caches. Cherche les papiers sur le compilateur de Self (http://selflanguage.org ), ou http://www.lirmm.fr/prm/language.html .
        
        [^]Re: ObjectiveC
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 21:26. (lien). Évalué à 2.
        Merci pour les liens! j'étudierais tout ça.
        
        En revanche, comme la table de lookup est partagée entre toutes les instances d'une même classe, je trouvais ça correct comme utilisation mémoire. J'ai plus souvent 10'000 objets avec 10 méthodes que 10 objets avec 10'000 méthodes.
- [^]Re: ObjectiveC
  
  Posté par Marc (Jabber id, page perso, ) le 26/06/2009 à 17:19. (lien). Évalué à 2.
  - Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.
  
  gcc inclue un frontal objc. Donc ton approche pourrait se justifier pour les cibles où gcc n'est pas porté, mais pour laquelle un autre compilo C existe. Mais là, on peut répondre qu'il existe des s2s objc->c (comme POC: http://users.telenet.be/stes/compiler.html ).
  
  (c'était juste pour info... sur le reste, j'ai pas d'avie pertinent à donner)
  - [^]Re: ObjectiveC
    
    Posté par Marc (Jabber id, page perso, ) le 26/06/2009 à 17:21. (lien). Évalué à 2.
    (c'était juste pour info... sur le reste, j'ai pas d'avie pertinent à donner)
    
    il parait même que ça s'écrit avis. Trop fou.
    
    (ah, et bien vu la geekscote lors de la détection de l'auto-réponse :D)
    - [^]Re: ObjectiveC
      
      Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 18:47. (lien). Évalué à 1.
      (eh oui, meme linuxfr se vend.. scandaleux, mais ou va le monde, etc.)
      
      Ha oui, bien vu le coup des source a source ObjC. Sont-ils bien aussi bien maintenus/compatibles que les compilateurs plus standards?
      - [^]Re: ObjectiveC
        
        Posté par Marc (Jabber id, page perso, ) le 26/06/2009 à 21:07. (lien). Évalué à 1.
        Aucune idée. Je sais qu'à l'époque où j'avais regardé, POC n'utilisait pas tout le système de typage de objc (c'est vague ce que je dis, normal, je m'en souviens plus très bien). Le truc à retenir, c'est que c'est faisable... Donc dire "on a refait un truc et pas continuer dans le sens objc parce que nous on génère du C donc on est plus portable", c'est pas bon. Après, je doute pas qu'il existe plein d'autres raisons valables ;)
    - [^]Re: ObjectiveC
      
      Posté par ∫ầřυårðīņ (page perso, ) le 27/06/2009 à 18:17. (lien). Évalué à 2.
      C'est normal que l'on n'ait plus d'Avie pertinent dans tout ce qui gravite autour d'Objective C : http://en.wikipedia.org/wiki/Avie_Tevanian
      
      --
      The elevation of 'faith' is, in fact, a sign that a religious tradition is losing its ability to induce theophany, or has already lost it.
- [^]Re: ObjectiveC
  
  Posté par Nicolas Roard (page perso, ) le 30/06/2009 à 03:18. (lien). Évalué à 2.
  
  - Objective-C met l'accent sur les décisions au temps de l'execution, alors qu'ooc essaie d'attraper les erreurs au temps de la compilation.
  
  Ben uniquement si tu le veux, sinon le compilo t'engueule hein...
  
  - Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.
  
  En meme temps vu que le compilo objc le plus utilise c'est gcc, on est a peu pres tranquille concernant la problematique du multi-plateforme ;-)
  
  Plus serieusement, il y a pas mal de trucs interessants fait en ce moment autour de LLVM, et David Chisnall a implemente un frontend Objective-C.
  
  Enfin, ooc est inspiré en partie de Java, lui-meme inspire (entre autres) d'Objective-C, lui-meme inspire de Smalltalk. Concrètement, Objective-C est un langage mature qui apparamment ne changera plus beaucoup. Cela permet une grande stabilité, mais le langage est condamné a rester dans ses habitudes: il est trop tard pour tirer les leçons du passé (par exemple, gcc semble ne pas supporter totalement ObjC 2.0). Par contraste, ooc est un jeune galopin qui essaie d'apprendre de ses grands-parents. Il est largement encore temps de s'impliquer et d'influer sur le design.
  
  J'allait justement souligner ObjC 2.0 -- pour un langage qui ne changera plus beaucoup, c'est un changement assez recent... (bon par contre, c'est en gros Apple qui pousse :-/)
  
  Pour ce qui est du support ObjC 2.0 dans gcc, pas sur a 100% mais il me semble que gcc supporte tout ce qu'il faut... mais libobjc non. ObjC est dynamique et utilise un runtime, i.e. libobjc sous linux, et le runtime NeXT sur OSX, qui lui supporte ce qu'il faut.
  - [^]Re: ObjectiveC
    
    Posté par Sebastien Binet () le 30/06/2009 à 10:42. (lien). Évalué à 1.
    objc-2.0 est intéressant mais l'absence de namespaces est quand même franchement 'rétrograde'...

Vala

Posté par Sytoka Modon (page perso, ) le 26/06/2009 à 15:25. (lien). Évalué à 9.

Dans le même genre, quelle est la différence avec Vala ?

[^]Re: Vala

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 15:37. (lien). Évalué à 6.
Comme le site officiel le précise, Vala et ooc sont très proches en philosophie. La différence fondamentale est que Vala est basé entièrement sur la GLib et son modèle objet. Cela apporte des avantages considérables (librairie mature et très bien conçue), mais aussi une dépendance d'un poids non-négligeable.

Par contraste, ooc se base uniquement sur la librairie standard C. Cela est avantageux tant en terme de taille que de déploiement sur des plateformes disons.. exotiques (je pense en particulier a Haiku, réécriture libre du défunt BeOS).

Ceci dit, Vala est un excellent langage que je recommande également de tester. Il est sans aucun doute l'avenir du développement des applications Gnome/GTK, vu son fort degré d'intégration avec ces librairies.
- [^]Re: Vala
  
  Posté par Kangs () le 26/06/2009 à 17:57. (lien). Évalué à 2.
  Juste une petite question comme container je ne vois que 'The Array class', as tu pour objectif d'offrir d'autre container (list, map, ... et algo associés) ?
  - [^]Re: Vala
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 18:05. (lien). Évalué à 2.
    Je sais pas quelle doc tu es en train de lire, mais en tout cas le Guide de référence du langage [http://ooc-lang.org/doc/langref/book1.htm] parle également de ArrayList et SparseList.
    Pour les maps & compagnie, il va falloir attendre la 0.3, qui ne saurait tarder =) Je rappelle au passage que tous ceux qui ont une âme charitable et souhaitent contribuer du code sont plus que les bienvenus. Tout le monde en profite.
    - [^]Re: Vala
      
      Posté par Kangs () le 26/06/2009 à 18:21. (lien). Évalué à 2.
      Je suis désolé si je suis un peu lourd, dans le chapitre "Chapter 1. Variables" je vois une brève référence à ArrayList et SparseList :
      "Array is a fixed-size type. To store a variable number of elements, see the ArrayList and SparseList classes."
      
      J'ai ouvert tous les chapitres et fait une recherche sur ArrayList, et je n'ai trouvé qu'une brève allusion qu'au chapitre 4.
      
      Elles ne sont pas encore documentées tes class ? (ou vraiment je suis lourd )
      
      Sinon je suis comptent qui tu en prévois d'autres ;)
      - [^]Re: Vala
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 18:38. (lien). Évalué à 4.
        Mais non t'es pas lourd. Les mecs lourd c'est "c'est pas LISP/Ruby/Python/Scala/D/C#"
        
        Donc oui ma foi tu as fort raison, le SDK pourrait être un peu plus documenté. En l'occurence, j'utilise une notation a la javadoc dans les sources, donc par ici tu devrais trouver ton bonheur: [http://github.com/amoswenger/ooc/tree/4a977fe092e18bd9cdaffe663b1519905deb0d23/sdk/structs]
        
        1000 fois désolé pour le manque de doc, j'ai déjà passé 2 nuits de suite a écrire le language reference guide, donc le reste viendra en son temps =)

[+] Et Vala ?

Posté par pix (page perso, ) le 26/06/2009 à 15:27. (lien). Évalué à -1.

Et qu'offre t'il par rapport a [[Vala_(langage_de_programmation)]] par exemple ?

--
La hiérarchie, c'est comme les étagères : plus c'est haut, moins ça sert.

Version 0.2

Posté par Thierry Thomas (Jabber id, page perso, ) le 26/06/2009 à 15:28. (lien). Évalué à 1.

Je comprends bien qu'un compilateur soit compliqué à développer, mais j'ai du mal à comprendre qu'un langage puisse « sortir » en version non stabilisée !

--
Th. Thomas.

[^]Re: Version 0.2

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 15:43. (lien). Évalué à 2.
C'est une excellente question, merci de l'avoir posée (si, si). En fait, pour l'instant, la définition du langage et l'implémentation de référence du compilateur évoluent en même temps. Il se trouve que la version 0.2 de chacun d'entre eux correspond a la "sortie" du "Language Reference Guide", [http://ooc-lang.org/doc/langref/book1.htm]. Il serait plus juste de dire que sont sortis en même temps "le brouillon 0.2 de la spécification du langage" et "la version 0.2 instable de l'implémentation de référence du compilateur". Mais ça faisait un peu long comme titre de dépêche.

lan_GA_ge

Posté par totof2000 () le 26/06/2009 à 15:36. (lien). Évalué à 6.

Sinon c'est quoi cette façon à obligner les gens a faire un commentaire quand tout est dit dans le titre? Vous voulez une insulte en plus ?

[^]Re: lan_GA_ge

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 15:39. (lien). Évalué à 2.
Argl, toutes mes excuses, passer sa nuit a rédiger la même nouvelle pour des sites officiels, ca laisse des traces :X Sincèrement désolé. (/me cherche le lien "Editer la dépêche")
- [^]Re: lan_GA_ge
  
  Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:29. (lien). Évalué à 1.
  * pour des sites anglophones, meme.
  
  hum.

hello world?

Posté par case42 (page perso, ) le 26/06/2009 à 16:11. (lien). Évalué à 3.

Ça fait maintenant dix minutes que je clique à droite et à gauche sur les différentes ressources, et je n'ai toujours pas vu le début du commencement d'un exemple de code... Il devrait y avoir un hello world en OOC ecrit en gros et gras sur la première page du site...

[^]Re: hello world?

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 16:21. (lien). Évalué à 1.
A peu près dans tous les chapitres du guide de référence du langage, il y a des exemples de code. [http://ooc-lang.org/doc/langref/book1.htm]

Sinon, la meilleure ressource pour les exemples reste le dépôt git: [http://github.com/amoswenger/ooc/tree/4a977fe092e18bd9cdaffe(...)]

Et pour la route, un petit hello world fait maison:
func main { printf("Hello, Linuxfr world =)\n"); }
- [^]Re: hello world?
  
  Posté par windu.2b (Jabber id, page perso, ) le 26/06/2009 à 17:17. (lien). Évalué à 4.
  Il est pas réglo, ton Hello World ! Il respecte pas les standards...
  
  :-p
  - [^]Re: hello world?
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 17:47. (lien). Évalué à 3.
    Je proteste. Donnez-moi le numéro de norme ISO concernant les hello world, et je normaliserais. Pas avant. =)
- [^]Re: hello world?
  
  Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 17:50. (lien). Évalué à 2.
  (comme le fait remarquer アントニドミ, j'ai suivi ton conseil et ajouté un petit exemple qui montre quelques possibilités du langage)

[^]Re: hello world?

Posté par アントニドミ () le 26/06/2009 à 17:15. (lien). Évalué à 3.
import os.Time;

/** The world must be getting tired of being said hello */
func main {
printf("Goodbye, world !\n");
new Bomb.start;
}

class Bomb {

func start {
for(Int i: reverse 1..11) {
printf("%d...", i);
fflush(stdout);
Time.sleepSec(1);
}
printf("BOOM!\n");
}

}

Ooc !

Posté par Pierre Bourdon (Jabber id, ) le 26/06/2009 à 18:03. (lien). Évalué à 6.

Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc! Ooc? Ooc. Ooc? Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc. Ooc? Ooc. Ooc! Ooc! Ooc? Ooc! Ooc. Ooc? Ooc! Ooc.

[^]Re: Ooc !

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 18:10. (lien). Évalué à 0.
coin? [http://hules.free.fr/wmcoincoin]
- [^]Re: Ooc !
  
  Posté par LupusMic (page perso, ) le 26/06/2009 à 20:38. (lien). Évalué à 4.
  Mais non voyons. Tu ne connais pas tes classiques : http://99-bottles-of-beer.net/language-ook!-515.html
  - [^]Re: Ooc !
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 20:42. (lien). Évalué à 1.
    Ooooooooooooh très juste. Je l'avais oublié celui-là, Je retiens mieux les langages avec des couleurs [http://www.dangermouse.net/esoteric/piet.html].

Succès du langage

Posté par letsyl () le 26/06/2009 à 19:07. (lien). Évalué à 6.

As-tu une barbe ?

[^]Re: Succès du langage

Posté par Kangs () le 26/06/2009 à 19:16. (lien). Évalué à 1.
D'après son site non, mais il crache bien ;)

[^]Re: Succès du langage

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 19:39. (lien). Évalué à 3.
J'y travaille depuis une semaine. Je suis pas sur que ma moitié sera du même avis (les femmes ne nous comprennent vraiment pas). Je ne peux pourtant pas me permettre de faire tache sur les photos entre Guido et Larry.
Mais de toute façon, Bjarne fait son rebelle, il se rase, lui!

Rapidité du C ... et ramasse-miettes ?

Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 20:15. (lien). Évalué à 1.

Je relève ce qui me semble être une petite contradiction dans la dépêche. Tu dis qu'OOC a la rapidité du C, mais ensuite tu dis qu'il utilise un ramasse-miettes.

Or ça c'est une contradiction: un ramasse-miettes ça a un coût en termes de performances et d'utilisation de la mémoire. Ce n'est pas sans raison que les langages orientés performance, ayant une philophie "aucun surcoût par rapport à l'assembleur", tels que le C et le C++, n'utilisent pas de ramasse-miettes.

http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc(...)

[^]Re: Rapidité du C ... et ramasse-miettes ?

Posté par Pierre Bourdon (Jabber id, ) le 26/06/2009 à 20:21. (lien). Évalué à 3.
Un GC peut améliorer les performances dans certains cas (notamment lorsqu'il y a beaucoup d'allocations et de désallocations, le GC maitrise mieux que le codeur comment optimiser tout ça). Cf. les trucs du genre « PyPy faster than C ».

Mais c'est bien entendu uniquement « dans certains cas ». Dans d'autres, ça ralentira effectivement le programme un peu, mais ça simplifie énormément la programmation (et ça évite de leaker à cause d'un free oublié quelque part).
- [^]Re: Rapidité du C ... et ramasse-miettes ?
  
  Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 21:18. (lien). Évalué à 2.
  La différence de fond, c'est que C et C++ sont des langages où "Tu ne paies que pour ce que tu utilises". Alors que les langages qui tiennent la main du programmeur, ajoutent un surcoût constant, que ce soit utile ou non.
  
  Pour ce qui est des fuites mémoire, le problème a largement disparu depuis l'apparition d'outils tels que valgrind. Franchement, tu fais "valgrind ./mon_programme", et bloum, tu vois toutes les fuites avec référence vers la ligne de code source fautive. C'est même beaucoup plus puissant que tout ce qu'un GC intégré à un langage peut espérer couvrir, parce que ça couvre non seulement ton programme mais aussi les librairies qu'il utilise, or une certaine partie des fuites mémoire ont lieu à cause d'un malentendu avec une librairie utilisée.
  - [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:37. (lien). Évalué à 5.
    Bah je dirais plutot que "C est un langage ou tout est presque gratuit mais tu te démerdes tout seul, ok?" et que "C++ est un langage pour lequel une fois que tu a l'abonnement, tu paies que ce que tu utilises (mais tarif double, pour des raisons de gestion interne)".
    
    Et puis comme je me lasse de me répéter, je vais citer Wikipédia pour changer, a propos des GC: "Many consider the penalty very small compared to the benefits it brings." [http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc(...)]
    
    Pour les fuites mémoires, heu, moui, moyen, je ne sais pas quelle est la complexité des structures de données des programmes que tu as du écrire en C, m'enfin il me semblait que même de très bon programmeurs devaient réfléchir a deux fois avant de gérer tout correctement.
    
    Quant a Valgrind, excellent outil, je l'utilise régulièrement pour résoudre des problèmes plus sérieux que des fuites (violation d'accès mémoire).
    
    J'ai rien contre ajouter l'option de désactiver le GC dans ooc, mais ca servirait strictement a rien, tout le SDK est codé dans l'esprit "on s'occupe pas de libérer la mémoire", donc dans ce cas là autant coder en C.
    
    Faut savoir choisir son langage, pour la tache qu'on a à accomplir. Qu'est-ce que tu penserais de quelqu'un qui se mettrait a utiliser du Java sur des téléphones mobiles ? (Oh, mais.. attendez.. ils le font.. Bizarre. Vraiment.)
- [+] [^]Re: Rapidité du C ... et ramasse-miettes ?
  
  Posté par JoeltheLion (page perso, ) le 26/06/2009 à 21:19. (lien). Évalué à -2.
  Un GC peut améliorer les performances dans certains cas (notamment lorsqu'il y a beaucoup d'allocations et de désallocations, le GC maitrise mieux que le codeur comment optimiser tout ça). Cf. les trucs du genre « PyPy faster than C »
  
  En théorie, oui. En pratique, je le croirai quand je verai un programme non écrit en C ou en C++ s'executer aussi vite. Pour l'instant, ça existe surtout dans les livres.
  
  --
  (pub: Autojump : une manière plus rapide de naviguer dans le système de fichiers avec la ligne de commande)
  - [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:27. (lien). Évalué à 2.
    C'est dur de répondre professionellement à la mauvaise fois.
    
    Déjà, tu pars du principe que C et C++ sont les deux langages les plus rapides. Notre cher LupusMic objecterait que tu confond langage et implémentation, et il aurait raison.
    
    Mais.. désolé de te décevoir. Comme example, les programmes écrits en Fortran sont généralement plus rapides (je laisse Google te rassurer sur ce point.)
    
    Ensuite, il y a des benchmark réels (je lis pas de bouquins sur les performances moi, je télécharge et compile les benchmarks existant) qui confirment ce que Pierre Bourdon dit.
    Pour pypy, c'est par ici: [http://morepypy.blogspot.com/2008/01/rpython-can-be-faster-t(...)]
    Pour Java, c'est par la: [http://kano.net/javabench/]
    Et pour ooc, un peu plus bas dans cette page (mais c'est un microbench assez insignifiant dans la discussion,)
    
    A noter que, comme ooc est traduit en C, ça n'a pas beaucoup de sens de "comparer les performances d'ooc a C", mais plutôt de "comparer malloc/free au Boehm GC".
    - [^]Re: Rapidité du C ... et ramasse-miettes ?
      
      Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 21:42. (lien). Évalué à 3.
      Déjà, tu pars du principe que C et C++ sont les deux langages les plus rapides. Notre cher LupusMic objecterait que tu confond langage et implémentation, et il aurait raison.
      
      Non: indépendamment du compilateur utilisé, il reste vrai que le C et le C++ ne forcent pas le compilateur à rajouter du code en plus de ce que le programmeur a écrit. Contrairement aux langages à ramasse-miettes.
      
      Il y a une toute petite exception avec certaines fonctionnalités du C++ (classes virtuelles etc) mais ces fonctionnalités ne sont pas obligatoires, on ne les utilise que si on en a l'usage, et même alors ça reste minimaliste de sorte qu'on ne pourrait pas obtenir la fonctionnalité équivalente à moins de frais.
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:47. (lien). Évalué à 1.
        Même argumentation, encore et encore. Si c'est pour utiliser C++ avec aucune des possibilités qui le rendent plus lent que le C, alors pourquoi utiliser C++?
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Pierre Bourdon (Jabber id, ) le 26/06/2009 à 21:50. (lien). Évalué à 1.
        Car en C++ on écrit sujet.verbe() plutôt que verbe(sujet), les gens trouvent ça plus naturel :) .
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:20. (lien). Évalué à 2.
        Bon ben il me reste plus qu'a implémenter un switch "-nogc" dans le compilateur ooc et tout le monde sera content?
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par alpage (Jabber id, page perso, ) le 27/06/2009 à 17:30. (lien). Évalué à 2.
        C'est pas objet.verbe() plutôt ? Du coup verbe(objet) serait plus naturel, du moins pour des francophones. À moins que C++ soit en fait un langage orienté sujet ?-)
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par pasBill pasGates () le 26/06/2009 à 22:11. (lien). Évalué à 6.
        Les templates sont une possibilite de C++ qui ne le rendent pas plus lent que C.
        
        Le mot cle const, la notion de private/public/protected , etc... ne coutent pas un centime non plus.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:23. (lien). Évalué à 2.
        C'est pas faux.

[^]Re: Rapidité du C ... et ramasse-miettes ?

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 20:24. (lien). Évalué à 2.
C'est une idée reçue malheureusement très répandue. La vérité est un peu plus complexe.

Sur un test réalisé par curiosité, la création de 1'000'000+ petits objets dans une boucle est environ 2x plus rapide en ooc qu'en C++ (qui n'utilise pas de GC, donc). Ces résultats, bien que peu fiables, confirment les études faites sur la performance des garbage collectors.

En pratique, une application qui alloue beaucoup de petits objets souvent tournera bien plus vite avec un garbage collector. En contraste, une application qui alloue peu de très gros objets tournera mieux en gestion de mémoire manuelle.

Pour de plus amples informations sur ce sujet, des diapos et documents expliquant les avantages/désavantages, je ne peux que vous référer a la page du GC utilisé par ooc: [http://www.hpl.hp.com/personal/Hans_Boehm/gc/]
- [^]Re: Rapidité du C ... et ramasse-miettes ?
  
  Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 20:39. (lien). Évalué à 2.
  Tiens d'ailleurs, je l'ai refait vite fait.
  
  Resultats:
  tsubaka tmp # time ./newbench_cxx real 0m8.048s user 0m7.859s sys 0m0.011s tsubaka tmp # time ./newbench real 0m3.322s user 0m3.279s sys 0m0.011s tsubaka tmp #
  
  Makefile:
  all: g++ newbench.cxx -o newbench_cxx ooc newbench
  
  C++:
  class Dummy { private: int i; public: Dummy(); void increment(); }; Dummy::Dummy() { this->i = 0; } void Dummy::increment() { this->i++; } int main() { for(int i = 0; i < 100000000; i++) { Dummy* d = new Dummy(); d->increment(); delete d; } }
  
  ooc:
  class Dummy { Int i = 0; func increment { i++; } } func main { for(Int i: 0..100_000_000) { new Dummy.increment; } }
  
  Comme tous les benchmarks, a prendre avec des pincettes.
  - [+] [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 21:32. (lien). Évalué à -1.
    Par défaut g++ n'optimise rien, il produit consciemment du code super lent pour que le résultat soit plus débuggable et que la compilation prenne moins longtemps.
    
    Donc ton makefile devrait dire à g++ d'optimiser:
    
    g++ -O2 newbench.cxx -o newbench_cxx
    
    Maintenant si tu te renseignais sur le C++ tu verrais que question performances il est strictement à égalité avec le C, donc le résultat de ton benchmark aurait pu te mettre la puce à l'oreille !
    - [^]Re: Rapidité du C ... et ramasse-miettes ?
      
      Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:40. (lien). Évalué à 2.
      C'est rigolo parce que j'avais prévu cette remarque.
      
      Malheureusement, tu aurais pu le constater par toi-même si tu avais fait l'effort de télécharger ooc et de compiler le benchmark.
      
      Voici donc les résultats avec -O2, dans les deux cas.
      
      Résultats:
      tsubaka tmp # time ./newbench_cxx_O1 real 0m8.439s user 0m8.354s sys 0m0.004s tsubaka tmp # time ./newbench_O1 real 0m3.402s user 0m3.301s sys 0m0.012s tsubaka tmp # time ./newbench_cxx_O2 real 0m6.911s user 0m6.790s sys 0m0.007s tsubaka tmp # time ./newbench_O2 real 0m2.813s user 0m2.767s sys 0m0.005s tsubaka tmp #
      
      Makefile:
      all: g++ newbench.cxx -o newbench_cxx_O1 ooc newbench mv newbench newbench_O1 g++ newbench.cxx -O2 -o newbench_cxx_O2 ooc newbench -backend=gcc,-O2 mv newbench newbench_O2
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 21:54. (lien). Évalué à 0.
        J'avais pas regardé de près le contenu de ton benchmark.
        
        Maintenant tout s'explique: c'est le bench dont tu parlais plus haut, qui crée et détruit un million de petits objets.
        
        Comme je te l'ai déjà dit, oui, bien sûr que sur un benchmark comme ça le GC permet d'aller plus vite. Je pensais que tu avais compris que dans toute situation on peut toujours trouver le benchmark sur mesure qui prouve ce qu'on veut. C/C++ restent plus rapides que n'importe quel langage à GC, parce qu'avec eux on peut utiliser un GC si l'on veut tout en pouvant aussi de _pas_ en utiliser un si ce n'est pas utile.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:04. (lien). Évalué à 1.
        [http://linuxfr.org/comments/1044014.html#1044014]
        
        Et maintenant?
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 22:30. (lien). Évalué à 1.
        Ben maintenant, l'écart de performance est déjà resserré; si tu as obtenu ce résultat avec -fno-exceptions, alors ma dernière idée est que je me souviens que delete accepte le pointeur nul contrairement à free(), donc si ça se trouve il y a un if(...) dans l'implémentation de delete.
        
        Bon bref il faut vraiment concocter un benchmark pas réaliste comme celui-là pour voir apparaître une différence! Pas réaliste, parce que de toute façon, même avec un GC, créer et détruire des millions de petits objets ça n'est pas efficace donc lorsque la vitesse est importante, on évite (par exemple en allouant un millier d'objets d'un coup).
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:41. (lien). Évalué à 1.
        Forcément que l'écart se resserre, on a déjà coupé les bras et les jambes d'ooc pour donner une chance a C++!
        
        Et puis bon, heu, écart resserré... 12% plus rapide quand meme, c'est pas rien il me semble.
        
        Allez, rajoutons un sac de pierres sur le dos d'ooc: [http://ooc.pastebin.com/m512a5d78]
        
        Et pourtant il ne bronche pas:
        tsubaka ooc_tmp_nogc_if # time ../../withgc/newbench_cxx_O1 real 0m8.014s user 0m7.907s sys 0m0.006s tsubaka ooc_tmp_nogc_if # time ./newbench_O1_nogc_if real 0m7.376s user 0m7.228s sys 0m0.006s tsubaka ooc_tmp_nogc_if # time ../../withgc/newbench_cxx_O2 real 0m6.842s user 0m6.738s sys 0m0.005s tsubaka ooc_tmp_nogc_if # time ./newbench_O2_nogc_if real 0m5.943s user 0m5.890s sys 0m0.005s
        
        Brave bête, ooc, brave bête.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 22:49. (lien). Évalué à 2.
        Oui c'est bon, mais faut pas passer à côté du point important qui est, je le répète, que ce benchmark n'est pas réaliste!
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:53. (lien). Évalué à 1.
        Disons qu'il ne teste qu'une petite partie de deux implémentations de deux langages.
        
        Si tu as les sources de benchmarks plus réalistes écrits en C++ je me ferais une joie de les porter en ooc pour poster les résultats comparatifs (avec en sans GC).
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Sytoka Modon (page perso, ) le 27/06/2009 à 00:32. (lien). Évalué à 3.
        Y'a pas un conteneur dans la STL pour faire ce que tu fais et du coup, profiter des bénéfices de la pré-allocation par la STL ?
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 00:47. (lien). Évalué à 2.
        Hmm je veux bien mais dans le contexte je vois pas comment. Tu pourrais poster un code d'exemple, stp ?
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par JoeltheLion (page perso, ) le 29/06/2009 à 11:02. (lien). Évalué à 5.
        Pourquoi ne fais tu pas ajouter ooc au benchmark debian? Si tu obtiens de meilleures performances que le c++ avec du code pas trop dégueulasse, je te garantis que ton nouveau langage aura du succès!
        
        --
        (pub: Autojump : une manière plus rapide de naviguer dans le système de fichiers avec la ligne de commande)
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:51. (lien). Évalué à 1.
        Maintenant, juste pour le "benchmark pas réaliste", ben en y réfléchissant bien, je suis pas si sur que ça. Plein de programmes Java sont over-orientés objets, je pense notamment côté serveur, les frameworks sont à mon sens horrible car remplis d'objets dans tous les sens, et pourtant ce sont des domaines ou la performance (enfin plutot la "scalability") est importante...
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par bbfok () le 26/06/2009 à 23:13. (lien). Évalué à 3.
        Free accepte un pointeur nul aussi. Dans le man :
        'If ptr is NULL, no operation is performed.'
        
        Je serais curieux de voir aussi ce que ca pourrais donner avec d'autres implémentations de malloc, notamment celle de google (TCmalloc) :
        http://goog-perftools.sourceforge.net/doc/tcmalloc.html
        
        --
        Remember tunnel seventeen !
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 00:11. (lien). Évalué à 2.
        Eh bien voilà un benchmark intéressant. Avec TCMalloc (fraichement compilé sur mon Core 2 Duo T5900), le C++ passe en tête !
        
        Je tiens a faire remarquer que le Boehm GC reste plus performant pour ce micro-bench que TCMalloc/C++, mais c'est bien normal.
        
        Je vais essayer avec l'allocateur Hoard aussi.
        
        tsubaka ooc_tmp_nogc # time ./newbench_cxx_O1 real 0m4.628s user 0m4.492s sys 0m0.003s tsubaka ooc_tmp_nogc # time ./newbench_O1 real 0m5.557s user 0m5.413s sys 0m0.005s tsubaka ooc_tmp_nogc # time ./newbench_cxx_O2 real 0m3.949s user 0m3.926s sys 0m0.003s tsubaka ooc_tmp_nogc # time ./newbench_O2 real 0m5.196s user 0m5.147s sys 0m0.005s tsubaka ooc_tmp_nogc # time ../../withgc/newbench_O1 real 0m3.456s user 0m3.245s sys 0m0.006s tsubaka ooc_tmp_nogc # time ../../withgc/newbench_O2 real 0m2.804s user 0m2.707s sys 0m0.013s
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 00:46. (lien). Évalué à 1.
        Nouveaux tests avec l'allocateur Hoard.
        
        Ici pas de gain de performance par rapport a dlmalloc (l'allocateur par défaut dans la glibc), au contraire. Par contre l'avantage est de nouveau légèrement au C++.
        
        Je suis bien curieux de ce qui provoque ces différences!
        
        tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_cxx_O1 real 0m7.449s user 0m7.338s sys 0m0.007s tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_cxx_O2 real 0m6.678s user 0m6.570s sys 0m0.006s tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_O1 real 0m7.496s user 0m7.354s sys 0m0.006s tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_O2 real 0m7.443s user 0m7.372s sys 0m0.011s
    - [^]Re: Rapidité du C ... et ramasse-miettes ?
      
      Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:46. (lien). Évalué à 2.
      Bon pour continuer:
      
      > Maintenant si tu te renseignais sur le C++ tu verrais que question performances il est strictement à égalité avec le C
      
      Ce n'est pas honnete. Si on utilise C++ exactement comme le C, alors, oui, comme le C++ est presque un superset du C, alors on a les memes performances.
      
      Ce qui m'interesse dans les comparaisons c'est la performance qu'on a en faisant les choses comme le langage les recommande. Et si, en C++ on utilise la STL, et qu'en C on utilise des pointeurs a tout va, je suis désolé mais on a pas du tout les mêmes performances. Voir la première partie du benchmark sur cette page: [http://unthought.net/c++/c_vs_c++.html]
  - [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par beagf (page perso, ) le 27/06/2009 à 10:27. (lien). Évalué à 2.
    Ton benchmark ne prouve qu'une chose, le C++ est plus lent que OOC quand tu lui demande de faire quelque chose de stupide et qu'en plus tu le fait mal.
    
    Il n'y a aucun interet au programme que tu montre et même pire, c'est une des plus mauvaise manière de faire cete chose sans interet. Lorsque un objet doit être alloué et libéré très rapidement et en très grande quantité, la bonne manière de faire est d'utiliser un pool d'objet, tout comme en C quand tu dois allouer et libérer un très grand nombre de petites zones mémoire, tu en alloue un gros paquet d'un coup que tu libère aussi en une fois à la fin.
    
    Tu pourras dire ce que tu veux, ce benchmark ne veut absolument rien dire. La seule bonne manière de faire un benchmark, indépendament du test lui même, c'est déjà de bien connaître les deux langages, et d'écrire un bon code pour chacun d'eux.
    
    Il suffit de regarder les résultats du shoutout pour s'en rendre compte, certains langages se retrouvent à la traine, non pas car ils sont réellement moins bon, mais uniquement car les benchs ont étés codés n'importe comment.
    
    Les benchs c'est super pratique, quand tu veux prouver quelque chose, en cherchant bien tu finis toujours par en trouver un qui approte la preuve que tu veux. Par contre dans la réalité, trouve moi un seul code qui fait quelque chose d'aussi stupide que ton bench.
    Dans la réalité, tu ne fait pas juste un ++ sur variable de ton objet mais tu fais un traîtement qui justifie la création de cet objet, donc l'allocation/libération à beaucoup moin d'impact sur les perfs et l'écart ce réduit.
    Ensuite dans la réalité, tu fais un profile de ton code et tu t'apperçois que cette gestion mémoire continue d'avoir un impact sur les perf, donc tu utilises un pool, et là, la version OOC n'a plus rien pour elle.
    
    Sur un exemple comme le tien, l'utilisation d'un pool permet d'exploser les perfs de OOC très simplement. Le nombre d'objets est connu à la base donc un seul malloc/free est nécessaire dans toutes la durée du programme.
    Moralité, même le programme OOC me semble écrit avec les pieds, lui aussi méritrait l'utilisation d'un pool ;-)
    - [^]Re: Rapidité du C ... et ramasse-miettes ?
      
      Posté par Antoine () le 27/06/2009 à 11:48. (lien). Évalué à 9.
      Sur un exemple comme le tien, l'utilisation d'un pool permet d'exploser les perfs de OOC très simplement.
      
      Il est incohérent de critiquer un microbenchmark « non réaliste » et d'expliquer ensuite que le C(++) permet des tas de micro-optimisations coûteuses en développement et en maintenance, comme si c'était « réaliste » de faire ce genre de micro-optimisations sur des applications de la vraie vie.
      
      On peut tout faire en C(++), certes, le truc c'est que pendant que tu passeras ton temps à écrire des tas de micro-optimisations (allocateurs spécialisés, pools d'objets pré-alloués...) et à traquer les inévitables fuites mémoire liées à une complication croissante des schémas d'allocation, le développeur utilisant un langage plus haut niveau aura écrit un logiciel à la couverture fonctionnelle trois fois plus grande, et qui apporte plus aux utilisateurs.
      
      D'autant, évidemment, que rien n'empêche ooc d'intégrer ce genre de micro-optimisations de façon transparente sans que le programmeur ait à lever le petit doigt ; c'est ce que fait Python avec beaucoup de petits objets par exemple.
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par beagf (page perso, ) le 27/06/2009 à 13:11. (lien). Évalué à 4.
        Il est incohérent de critiquer un microbenchmark « non réaliste » et d'expliquer ensuite que le C(++) permet des tas de micro-optimisations coûteuses en développement et en maintenance, comme si c'était « réaliste » de faire ce genre de micro-optimisations sur des applications de la vraie vie.
        
        Ta critique ne tient (et encore que vaguement) que dans le cadre de ce micro-bench. Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
        
        Tout d'abord, tu trouvera de nombreuse classe sur le net, déjà testées intensivement, qui implémentent ce genre de pool. Donc le cout de dévellopement à ce niveau est quasiment nul. Tu commence par créer un pool en lui donnant éventuellement une indication du nombre d'élément que tu pense créer, et ensuite tu lui demande et et éventuellement redonne les objets de la même manière que les allouerais/libererais de manière classique. Avec l'avantage que tu as un netoyage global à la fin en libérant le pool.
        Donc tu peut même gagner du temps dans certains cas, en éliminant la nécéssitée de libéré les objets au fur et à mesure.
        
        Ensuite, un objet qui doit être créer à suffisament d'exemplaire pour qu'utiliser un pool soit vraiment intéressant c'est pas forcément tous les jours que tu en rencontre. Donc de base c'est le genre de chose auquel on a tendance à penser au moment ou l'on prévoit le design de l'application, pas en dernière minute.
        
        De manière plus générale, l'utilisation d'un pool n'est pas, comme tu le dis, une «micro-optimisation» mais un point de design et dans des programme réaliste, les cas ou tu dois le mettre en oeuvre ne sont pas si fréquents, sont bien prévu, et au final ne complexifie pas le code mais on tendance à le simplifier beaucoup quand c'est bien fait.
        
        Avec quelque classes génériques, tu obtient les avantage de la gestion manuelle et des GC. Dans les zones qui n'ont pas être rapide, tu peux utiliser la libération automatique, les auto pointer... Et dans les zones critiques tu utilises une gestion manuelle et des pool automatique quand c'est nécéssaire.
        
        Le développeur utilisant un langage plus haut niveau aura écrit un logiciel à la couverture fonctionnelle trois fois plus grande, et qui apporte plus aux utilisateurs.
        
        C'est un joli mythe mais dans la réalitée c'est loin d'être toujours le cas. Il y a énormément de chose qui jouent dans ta capacité à produire du code et le niveau d'abstraction ou de fonctionalité du langage n'est pas la plus importante.
        
        De manière générale il faut être capable de choisir le langage adapté à la tache et à l'environement. Je n'utilserais pas du C pour faire un programme qui fait des manipulations complexe de chaine de caractère sur un petit volume de donnée une fois par mois, tout comme je n'utilserais du bash pour faire un calcul scientifque complexe qui tournera sur un gros serveur de calcul.
        
        Pour revenir au sujet de base : le garbage collector, J'ai eu un soucis il y a de cela quelque temps :
        Un petit programme pas extrèmement compliqué qui lisait un fichier ligne par ligne. Il découpait la lignes, faisait quelques traitement et reassemblait une nouvelle ligne pour la sortie.
        J'ai fait une première version de ce programme en Lua, ce fut rapide à programmer, mais le programme devenait vite lent à mourir des que le fichier grossisait un peu.Sur le moment je n'avais ps le temps de chercher plus loin, j'ai donc recoder le truc en C en au final c'est les disque qui ne suivait plus le rythme. (ce qui dans mon cas n'était pas génant puisque la sortie du programme était traiter par un autre programme qui prenait le reste du temps CPU)
        Quelques temps plus tard, je me repenche sur le problème pour en déterminer la cause. J'aime beaucoup utiliser des langages de scripts pour prototyper des programmes ou pour des petits dévellopement qui n'on pas à être particulièrement rapide. Lua est un langage que j'apprécie beaucoup et donc j'avais envie de savoir d'ou venait vraiment le problème. Après investigation, le problème venait à la fois du GC et du fait que les chaine sont imutables dans lua : chaque ligne représentait un objet, mais aussi chaque morceau de la ligne découpée, chaque étape de transformation de ces morceaux ainsi que la ligne finale. Ce qui fait que pour chaque ligne traité, de nombreux petits objets était créés et le GC se déclenchait sans arret et libérait tous ceux des lignes précédentes. Bref pas mal de boulot inutile.
        La version en C utilisait juste deux buffer alloués statiquement.
        
        Cet exemple est, en partie, lié à la gestion des chaines imutable de lua, mais surtout met en avant le problème de ces langages de haut niveaux : Il y a beaucoup de choses qui sont cachées et que l'on ne peut pas forcément prédir et dont on ne connait pas forcément les conséquences. Et l'utilisation d'un GC peut cacher certains problèmes qui serait explicite sans eux.
        
        C'est quand tous les outils, il font utiliser le bon au bon moment, c'est tout.
        
        Donc, pour en revenir au bench, je maintient que celon moi il est stupide et ne prouve qu'une chose, quand on demande à C++ de faire quelque chose de stupide et qu'on lui demande mal, il est plus lent que OOC.
        Ce qui ne donne aucune information sur les perfs réelles de OOC.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 17:44. (lien). Évalué à 3.
        *sifflote*
        
        > Ton benchmark ne prouve qu'une chose
        Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
        
        > Il n'y a aucun interet au programme que tu montre
        Ma foi je vois pas pourquoi tu prends la peine de le critiquer alors.
        
        > ce benchmark ne veut absolument rien dire
        C'est pas ce que j'ai répété dans presque tous mes posts en haut? La seule chose que j'ai suggérée, c'est que pour une tâche très précise (et codée naivement) mais finalement pas si irréaliste, les résultats du microbench semblaient montrer qu'ooc implémentait les classes de manière plus légère, c'est tout. Les tests suggérés par bbfok avec l'allocateur TCMalloc montre qu'à conditions égales, le C++ peut outperformer ooc si on prive ce dernier de son GC activé par défaut. Il me semble pas avoir posté "HOLY SCHMOLY, OOC 0.2 BLOWS C++ AWAY"
        
        > les benchs c'est pratique quand tu veux prouver qqch
        ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
        
        > en réalité tu ne fais pas un ++ sur variable
        c'est marrant parce que j'ai écrit plein de programmes dans ma vie et j'ai souvent utilisé ++. Plus sérieusement, tu crois pas que si je faisais rien ave l'objet, je courrais le risque que g++/gcc se sente fou et me vire carrément ma boucle? Mieux vaux etre doublement sûr.
        
        > Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
        il a raison! tout le monde sait par exemple que Firefox gère parfaitement sa mémoire, et n'a jamais eu historiquement de grosses fuites mémoires et qu'il n'ont pas du tout passé des mois a essayer d'optimiser leurs routines d'allocations mémoire (comme ne le confirme pas le lien posté plus haut par son-nom-m'échappe)
        
        > Avec quelque classes génériques, tu obtient les avantage de la gestion manuelle et des GC. Dans les zones qui n'ont pas être rapide, tu peux utiliser la libération automatique, les auto pointer... Et dans les zones critiques tu utilises une gestion manuelle et des pool automatique quand c'est nécéssaire.
        
        Bon eh bien voilà une suggestion intéressante. A la réflexion, je ne vois pas de bonne raison de "forcer la main" des programmeurs ooc et de leur imposer le gc. J'entrevois la possibilité de pouvoir spécifier dans le code quel type d'allocation on préfère a l'instanciation: GC, pool, ou manuel. Tout ça intégré dans le langage, comme Antoine le suggère.
        
        > il faut être capable de choisir le langage adapté à la tache et à l'environement.
        eeeeeeeh copieur c'est moi qui l'ai dit en premier ça. (et pas qu'une fois en plus). Si y'a triche, moi je joue plus hein.
        
        > C'est un joli mythe mais dans la réalité c'est loin d'être toujours le cas.
        A cette différence près c'est que quand tu codes dans un langage bien établi comme le C++ tu regarde tristement la réalité en face, tu soupires, et tu remets a coder de manière fastidieuse parce que c'est trop tard pour changer (oui je connais le standard C++0x, et j'avoue que ça m'impressione: ils ont réussi à rendre le langage encore plus complexe et error-prone qu'avant. Je pensais pas que c'était possible.)
        
        > strings immutables (oh oui), et cacher des choses dans les langages de haut niveau.
        J'ai toujours été dubitatif quant a l'intérêt de l'immutabilité des Strings en Java (puisque c'est le langage avec lequel j'ai travaillé le plus), à part pour ceux qui ne savent pas ou ils passent leur Strings (auquel cas il faudrait penser sérieusement a arrêter la biosson, mon vieux). En résumé, ooc n'impose pas l'immutabilité d'une String.
        
        Quant a cacher des choses dans les langages de haut niveau ben à ce moment là.. C++ par exemple. Cf. [http://yosefk.com/c++fqa/] mais aussi [http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp]
        Pour ooc, rien n'est caché: l'implémentation du langage est simple, et tout ce qu'on a besoin de savoir sur comment c'est fait en dessous est dans le language reference guide (et si ça n'y est pas, c'est que ça manque, prévenez-moi et je complèterais.) L'avantage? Travailler avec un langage qu'on peut facilement maîtriser, se rendre compte qu'on a fait la même chose en C à la main depuis longtemps, et être même capable de faire des contributions valables au langage.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par beagf (page perso, ) le 27/06/2009 à 19:04. (lien). Évalué à 3.
        > Ton benchmark ne prouve qu'une chose
        Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
        Pour entrer dans le jeu, ça prouve juste que ça ne prouve rien ;-)
        
        > Il n'y a aucun interet au programme que tu montre
        Ma foi je vois pas pourquoi tu prends la peine de le critiquer alors.
        Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
        
        > ce benchmark ne veut absolument rien dire
        C'est pas ce que j'ai répété dans presque tous mes posts en haut?
        Bah non ce n'est pas ce que tu as répété come tu le dis si bien juste après :
        
        La seule chose que j'ai suggérée, c'est que pour une tâche très précise (et codée naivement) mais finalement pas si irréaliste, les résultats du microbench semblaient montrer qu'ooc implémentait les classes de manière plus légère, c'est tout. Les tests suggérés par bbfok avec l'allocateur TCMalloc montre qu'à conditions égales, le C++ peut outperformer ooc si on prive ce dernier de son GC activé par défaut. Il me semble pas avoir posté "HOLY SCHMOLY, OOC 0.2 BLOWS C++ AWAY"
        
        Une tâche très précise qui ne se produit jamais en dans un vrai code et en plus mal coder de manière à déformer les résultats du bench ? Ça c'est du bench intéressant...
        Tout ce que tu réussit à faire avec ton bench c'est dire «dans un cas que vous ne rencontrerez jamais dans la réalitée OOC fait mieux que C++ (et encore /une/ implémentation de C++), mais pour des cas réaliste je vous laisse deviner.»
        Moi quand je vois ce genre de bench, je trouve que ça pue la mauvaise fois et que le dev à chercher un moyen de montrer à tout pris que son langage est meilleur, et pour ça il à chercher le seul code ou c'est le cas. Quel que soit ton objectif, se genre de bench ne peut que te désservir.
        Soit tu ne fais pas de bench, soit tu en fais un serrieux, mais avec un comme celui là tu ne fais que décrédibiliser ton langage.
        
        ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
        Tout d'abord ce que tu fais n'est pas un vrai bench dans le sens ou tu biaise un des langages testés en l'utilisant mal. Si je fais un bench entre du C du CAML je peut déjà te dire que CAML sera dix fois plus lent et pourtant certains on montrer qu'il avait des perfs honorables.
        Ensuite où est l'interet d'un bench qui mesure des performances même vagues dans des conditions telles qu'elles ne seront jamais rencontrer dans aucun programme ?
        
        > en réalité tu ne fais pas un ++ sur variable
        c'est marrant parce que j'ai écrit plein de programmes dans ma vie et j'ai souvent utilisé ++. Plus sérieusement, tu crois pas que si je faisais rien ave l'objet, je courrais le risque que g++/gcc se sente fou et me vire carrément ma boucle? Mieux vaux etre doublement sûr.
        Je pense que tu le fais exprès mais au cas ou... Je ne critique pas le fait que tu fasse un ++, ce que je critique c'est que tu ne fasse que ça. Tu as souvent écrit des programme qui créait un million d'objet pour juste faire un ++ sur une variable et ensuite libéré l'objet ?
        Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ? C'est ce point qui est important. Ce qu'il faut te poser comme question c'est, qu'ai je sacrifier pour ça et est-ce que ça vaut le cout ?
        C'est la même chose que l'argument classique en faveur des GCs : On perd générallement un petit peu en perf mais on y gagne une facilitée d'utilisation.
        Tu gagne par rapport à C++ lors de la création de grande quantitée d'objet sans utilisation de pool, mais dans des condition réelle ou chaque objet réalise un vrai traitement tu ne gagne qu'un pouième de perfs, est-ce que c'est valable ? est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
        (vrai question puisque je ne sais pas comment marche OOC)
        
        > Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
        il a raison! tout le monde sait par exemple que Firefox gère parfaitement sa mémoire, et n'a jamais eu historiquement de grosses fuites mémoires et qu'il n'ont pas du tout passé des mois a essayer d'optimiser leurs routines d'allocations mémoire (comme ne le confirme pas le lien posté plus haut par son-nom-m'échappe)
        Là j'ai du mal à voir le rapport avec Firefox. Si j'écrit une appli en OOC qui à plein de fuite mémoire ça veut dire que OOC est une merde ?
        Le gros problème de Firefox c'est que la gestion mémoire à été conçue progressivement en rajoutant des couches petit à petit. Le lien que tu indiques montre que la mémoire se fragmente et donc qu'elle ne peut être récupéré par le système. Ce problème n'est pas lié au C++ ou à des pool ou n'importe quoi d'autre, un GC aurra éxactement le même.
        
        Si tu allous un million de petits objets et que tu en libère un sur deux, quel que soit le système que tu utilises tu ne pourra pas libéré la mémoire. A moin d'utiliser un GC compacteur mais là ça pose d'énorme problème puisque tout les pointeur doivent être indirects.
        Bien au contraire, un système de pool peut même améliorer la situation car il t'assure que les objets de même types sont regroupés au même endroit, donc il facilite la gestion.
        
        Bon eh bien voilà une suggestion intéressante. A la réflexion, je ne vois pas de bonne raison de "forcer la main" des programmeurs ooc et de leur imposer le gc. J'entrevois la possibilité de pouvoir spécifier dans le code quel type d'allocation on préfère a l'instanciation: GC, pool, ou manuel. Tout ça intégré dans le langage, comme Antoine le suggère.
        Ça c'est déjà mieux. Intégrer dans le langage ce que l'on fait de manière plus crade en C++ serait pas mal à condition que ce soit fait proprement ;-)
        
        > il faut être capable de choisir le langage adapté à la tache et à l'environement.
        eeeeeeeh copieur c'est moi qui l'ai dit en premier ça. (et pas qu'une fois en plus). Si y'a triche, moi je joue plus hein.
        D'un autre côté, ça fait des années que je le dis, et je suis sûr que d'autres l'on dis avant nous. Heureusement qu'il n'y a pas encore de brevets sur les opinions....
        
        > C'est un joli mythe mais dans la réalité c'est loin d'être toujours le cas.
        A cette différence près c'est que quand tu codes dans un langage bien établi comme le C++ tu regarde tristement la réalité en face, tu soupires, et tu remets a coder de manière fastidieuse parce que c'est trop tard pour changer (oui je connais le standard C++0x, et j'avoue que ça m'impressione: ils ont réussi à rendre le langage encore plus complexe et error-prone qu'avant. Je pensais pas que c'était possible.)
        Pour le C++, j'ai un ensemble classes et de templates que je réutilise à chaque fois que j'en ai besoin et qui me font ce genre de merde toutes seules. Ensuite, c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
        Et pour retourner le compliment, j'ai vu des programmeur (paix à leurs âmes) qui, obligé de programmer dans un langage qui pensait savoir mieux qu'eux comment gérer la mémoire était obliger de passer par de grand tableaux d'objets pour émuler les pool si simple à coder en C ou en C++. Bien sûr c'est pas des cas courrant, et c'est loin d'être systématiquement valable, mais ça arrive à mon avis plus souvent que créer un million do'bjets juste pour faire un ++....
        
        > strings immutables (oh oui), et cacher des choses dans les langages de haut niveau.
        J'ai toujours été dubitatif quant a l'intérêt de l'immutabilité des Strings en Java (puisque c'est le langage avec lequel j'ai travaillé le plus), à part pour ceux qui ne savent pas ou ils passent leur Strings (auquel cas il faudrait penser sérieusement a arrêter la biosson, mon vieux). En résumé, ooc n'impose pas l'immutabilité d'une String.
        Je ne lance pas le débat sur l'immutabilité des string mais sur le fait qu'il est dangeureux de cacher des chose, surtout dans les éléments de base d'un langage. Je voulais surtout montrer les effets pervers que peuvent avoir dans certains cas le GC et bien expliquer que ce n'est pas la solution ultime et que la gestion manuelle de la mémoire n'est pas le mal absolu.
        
        Quant a cacher des choses dans les langages de haut niveau ben à ce moment là.. C++ par exemple. Cf. [http://yosefk.com/c++fqa/] mais aussi [http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp]
        Pour ooc, rien n'est caché: l'implémentation du langage est simple, et tout ce qu'on a besoin de savoir sur comment c'est fait en dessous est dans le language reference guide (et si ça n'y est pas, c'est que ça manque, prévenez-moi et je complèterais.) L'avantage? Travailler avec un langage qu'on peut facilement maîtriser, se rendre compte qu'on a fait la même chose en C à la main depuis longtemps, et être même capable de faire des contributions valables au langage.
        Et le jour ou un programmeur stockera un poiteur vers un objet de manière un peu cryptée ou utilisera une variable entière dont la valeure est la même que l'adresse d'un objet qui traine quelque part, le Bohem GC va se planter et l programmeur aurra une surprise...
        J'admet que le premier cas relève d'une connerie de la part du programmeur, mais le deuxième est tout à fait réaliste.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 20:28. (lien). Évalué à 2.
        Bah je suis déçu, t'as compris que la moitié de mon deuxième degré. Je répond court parce que je commence a saturer (et puis, dans la vie, on nourrit les trolls en discutant ou on les tue en codant, hein..)
        
        > ça prouve juste que ça ne prouve rien ;-)
        +1
        
        > Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
        si tu vois pas l'intérêt d'un micro-bench, alors n'en parle même pas. Critiquer quelque-chose est utile uniquement si tu penses que ça peut l'améliorer. Penses-tu sérieusement t'impliquer dans le développement d'ooc?
        
        > Bah non ce n'est pas ce que tu as répété
        bizarrement, on dirait qu'on peut répéter 2 choses a la fois, dont "Ces résultats, bien que peu fiables [,,,]", "J'ai déjà moi-même dit et répété qu'un micro-benchmark ne voulait pas dire grand-chose", "Comme tous les benchmarks, a prendre avec des pincettes.", "Si tu as les sources de benchmarks plus réalistes écrits"
        
        Donc non seulement tu prêches a un converti mais en plus tu pars du principe que c'est un mauvais programmeur. Je te suggère d'imaginer la situation suivante: un programme divisé en 10 sous-systèmes, qui exécutent tous 100 tâches en "parallèle" pour chacun de leurs 100 clients (ou requêtes). Chacune des tâches a besoin d'allouer environ 1000 objets, de types et de taille différentes (aucun intérêt de pooler, donc). Qu'obtient-on? entre autres choses (calcul, entrées/sorties, etc.), 100 millions d'allocation d'objets en quelques secondes, à savoir le micro-benchmark ci-dessus. Sauf que ce programme que je te demande d'imaginer (mais qui ressemble bien a plusieurs programmes réels et en production) n'est pas si facilement optimisable qu'un micro-benchmark, précisément parce que les allocations sont de tous types et disséminées partout dans le code. D'où l'intérêt de tester la vitesse pure d'allocation. Avec tout le côté hasardeux, imprécis, et générateur de troll que ça a.
        
        > Moi quand je vois ce genre de bench, je trouve que ça pue la mauvaise fois et que le dev à chercher un moyen de montrer à tout pris que son langage est meilleur, et pour ça il à chercher le seul code ou c'est le cas. Quel que soit ton objectif, se genre de bench ne peut que te désservir. Soit tu ne fais pas de bench, soit tu en fais un serrieux, mais avec un comme celui là tu ne fais que décrédibiliser ton langage.
        Bah. Ce que tu dis serait valable si j'en avais fait tout un fromage en clamant a tout va qu'ooc est plus rapide que C++ de manière générale et si j'en avais fait une raison d'adopter ooc, dans mon argumentation. Or ce n'est pas le cas.
        
        Pour ce qui est d'un benchmark sérieux, je n'ai pas le temps dans la semaine qui vient, mais par simple curiosité (non, je ne suis pas si obsédé que ça par les performances) j'essayerais d'en trouver un potable (qui teste plusieurs aspects). Je pensais porter alioth shootout, a un moment. Mais bon "premature optimization is the root of all evil" donc je vais plutot me concentrer sur une langage plus propre et syntaxiquement bien plus sympathique que le C++ (enfin c'est mon avis..)
        
        > Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ?
        Je ne comprend pas la question. Je ne vois pas de prix a être plus léger, sinon éventuellement en facilité d'utilisation, ce qui n'est clairement pas le cas, de plus ta remarque qui suit présent l'argument exactement inverse.
        
        > est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
        Ben c't'a dire que non puisque la performance n'était pas du tout ma raison principael de faire/d'utiliser ooc. Ce qui me chagrinait en principal dans le C++ était la syntaxe, et l'absence d'une ABI standard.
        
        > j'ai du mal a voir le rapport avec Firefox
        Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
        Ma réponse : "va dire ça aux devs de grosses applications."
        
        > c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
        Pour info, C++0x est le futur du C++. Si son futur est bouseux (d'après toi) c'est pas vraiment ma faute.
        
        > j'ai vu des programmeurs obligés de se mettre au jiu jitsu pour faire des pools dans le langage X
        Je comprend que tu as cette discussions uniquement par fierté, par fanatisme du C++&co, et pour afficher ton grand savoir, mais tu pourrais faire l'effort de lire ce que je raconte sur l'avenir d'ooc. Résumons, à l'avenir: 3 options intégrées dans le langage: GC, pool, et malloc/free manuel. Et pour les allocations par blocs, une syntaxe comme "Object o = 300 new Object()" devrait faire l'affaire.
        
        > mais le deuxième est tout à fait réaliste.
        Absolument, c'est un des défauts connus des GC conservatifs. D'où le fait que je considère l'éventualité, comme ooc est fortement typé, d'en réécrire un précis pour les prochaines versions.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par beagf (page perso, ) le 27/06/2009 à 21:11. (lien). Évalué à 2.
        Je vais résumé mon point de vue en essayant d'être plus clair car j'ai l'impréssion que ce n'était pas le cas : Un bench qui n'est pas fait correctement, même s'il peut être marrant quand on le fait dans son coin, fait du mal au langage de manière général quand il est public comme celui que tu propose ici :
        - Tu peut mettre tous les avertissement sur le fait que ce que tu vas dire est une grosse connerie, il y aura toujours des personnes pour reprendre tes chiffres et les utiliser comme une parole d'évangile. Les gens aiment les chiffres même lorsqu'ils sont faux, il suffit de regarder les débats sur les perfs de java ou autres langage de haut-niveau ;
        - Pour quelqu'un qui regarde le bench d'un peu plus près, tu donne l'impression d'avoir chercher un cas à tout pris où tes perfs sont meilleur que celle du langage auquel tu te compare (même si ce n'est pas forcément le cas) donc tu perd toute crédibilité. Donc même si ton langage est bon, tu pousse les gens que cela pourrait intéresser à passer leur chemin.
        
        Ce que je critique dans mes message c'est principalement le fait de publier un bench tels que celui que tu donne. Les chiffres que tu donne ne veulent strictement rien dire à l'exception d'un cas très particulier qui n'apparait pas jamais dans la vraie vie. Le programme auquel tu l'oppose est trivialement mal programmé pour quelqu'un qui connait le C++, alors que l'on peut supposer que celui en OCC est bien codé puisque c'est ton langage, on peut donc en déduire que tu est de mauvaise foie.
        
        Bref, même si cela part d'une bonne intention, je pense que ton bench fait plus de mal qu'autre chose, et c'est général pour les mauvais benchs. Après, c'est peut-être moi qui suit tordu et qui voit le mal partout, mais au niveau bench j'ai vu le meilleur comme le pire, et j'ai pris l'habitude de me méfier de chiffre donnée sur la base des micro-bench.
        Mais de ce que j'ai pus voir les gens gobent ces chiffre aveuglément et globalement c'est plus facile de ce battre contre les mauvais bench que contre les idées qu'ils ont répendues.
        
        [...]exemple avec plein de systeme qui créent des objets dans tous les sens[..]
        Ton exemple illustre tout à fait ce que je critique, même si la création/libération des objets est un facteur important : dans le cas que tu illustres, il y a beaucoup de chose qui ce passe en plus de ces opérations. Notament, et c'est souvnt très important les objets sont rarement libérés dans le même ordre qu'ils sont créés, certains ont une durée de vie bien plus longue que les autres, beaucoup de paramètres entrent en jeu. Au final on est très loin de la situtation idéale du micro-bench que tu présente.
        Résultat : dans ce cas réaliste les perfs du GC doivent chuter dramatiquement et au final les perfs sont surement au mieux similaires à celle du C++.
        
        Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
        Ma réponse : "va dire ça aux devs de grosses applications."
        Ne me fais pas dire ce que je n'ai pas dit. Nulle part je ne dit que gérer la mémoire sans GC est trivial. Ce que je dis c'est que,dans un cas comme celui de ton micro bench, l'utilisation d'un pool est très simple : un grand nombre d'objet tous de même taille à allouer et libérer dans une portion réduite du code.
        De manière générale, l'utilisation de pool reste relativement simple tant que tu restes sur l'allocation d'un grand nombre d'objets identiques et dans ces cas là, c'est à ma connaissance toujours plus éfficace d'utiliser un pool qu'un GC.
        Si tes objets sont de tailles variable et contiennent des références les un aux autres, je suis d'accord qu'un GC deviens intéressant et qu'un pool n'est plus adapté.
        
        Je comprend que tu as cette discussions uniquement par fierté, par fanatisme du C++&co, et pour afficher ton grand savoir, mais tu pourrais faire l'effort de lire ce que je raconte sur l'avenir d'ooc. Résumons, à l'avenir: 3 options intégrées dans le langage: GC, pool, et malloc/free manuel. Et pour les allocations par blocs, une syntaxe comme "Object o = 300 new Object()" devrait faire l'affaire.
        Je suis loin d'être un fan du C++ contrairement à ce que tu dis, j'ai parlé du C++ car ton bench comparait OCC à C++ uniquement. Donc si tu veut délirer sur ma fierté et mon grand savoir libre à toi, mais fais comme pour le bench qui ne veulent rien dire, s'il te plait, ne les publies pas.
        Pour ton information et pour t'éviter de me relire, je suis pour le choix de la solution adaptée à chaque problèmes, et donc dans le cadre de ton micro bench pour la version en C++ c'est un pool et pas une gestion basique qu'il faut utiliser.
        L'avenir de OOC et le fait de pouvoir utiliser plusieurs modèles d'allocation mémoire c'est au dernier message que tu as commencé à en parler, je t'ai même répodu que ce serait bien de le faire, donc depuis que tu en parle, je pense l'avoir lut et en avoir tenu compte...
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 21:40. (lien). Évalué à 1.
        Merci pour les éclaircissements, on va pouvoir finir cette conversation sur un ton constructif =)
        
        Je résume donc ma position
        
        le but d'ooc n'est pas d'être le langage le plus rapide, mais plutôt de réduire le temps de développement, d'être portable, sans machine virtuelle, et libre.
        effectivement, le micro-benchmark présent dans les discussions ne prouve rien, et de plus il n'est pas du tout un bon exemple de programmation (comme tous les micro-benchs)
        un résultat plus significatif est la taille du code source ^^ 2x plus court en ooc
        à l'avenir, je prévois de laisser plus de flexibilité quant a la gestion de mémoire en ooc
        toutes mes excuses aux gens que j'ai froissé au passage
        
        (ah et pour "c'est au dernier message que tu as commencé à en parler", en fait c'est a un autre endroit du thread de commentaires que j'en parlais)
        
        Ah et sinon, quelqu'un sur reddit m'a conseillé d'implémenter un alorithme de "escape analysis", ce qui permet d'avoir un modèle déterministe de gestion de mémoire, sans GC, sans pool, et automatique. Voir la discussion avec les liens ici: [http://www.reddit.com/r/programming/comments/8vsgh/ooc_progr(...)]
- [+] [^]Re: Rapidité du C ... et ramasse-miettes ?
  
  Posté par LupusMic (page perso, ) le 26/06/2009 à 20:49. (lien). Évalué à -2.
  Si tu avais une connaissance approfondie du C++ tu saurais que ton bench n'a aucune valeur, puisque tu testes non pas le langage mais les performances de l'implémentation de l'allocateur par défaut (std::allocator<>). C'est allocateur est parfaitement personnalisable, et ce de manière générique.
  
  Et pour le garbage collector, on a bien std::auto_ptr<> (ainsi que boos::scoped_ptr<> et boost::shared_ptr<>) qui peut faire le travail.
  
  De toute façon, je préfère automatiser la libération de la mémoire, parce qu'il est humainement impossible de gérer correctement ces ressources de manière parfaite.
  - [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par Pierre Bourdon (Jabber id, ) le 26/06/2009 à 20:54. (lien). Évalué à 1.
    Euh... std::allocator c'est pas seulement pour les conteneurs de la STL ?
    
    Car l'implémentation par défaut de std::allocator chez moi se base sur new, ça serait un peu le serpent qui se mord la queue si ce que tu dis se confirme.
    - [^]Re: Rapidité du C ... et ramasse-miettes ?
      
      Posté par LupusMic (page perso, ) le 26/06/2009 à 21:44. (lien). Évalué à 1.
      new est un opérateur comme les autres, tu peux le surchargé. Et c'est ce qui est fait dans l'implémentation de base me semble-t-il. Donc à un moment donné, tu peux toujours réécrire la spécialisation de new. Du coup, ça ne se mort pas la queue.
      
      Faut que je fouille pour comprendre le mécanisme exact de ce qui se passe.
  - [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:05. (lien). Évalué à 1.
    ...
    
    Je suis d'accord pour me faire démonter mon microbench, mais seulement si le démontage est techniquement correct.
    
    En l'occurence... quelqu'un pourrait-il m'expliquer en quoi auto_ptr, shared_ptr, et autres joyeusetés du genre ont de commun avec un vrai garbage collector tel qu'on peut trouver dans Java (et oui c'est une référence, voir le nouveau collector G1 dans le JRE 1.6u14), python, etc. ou dans n'importe quel langage un tant soit peu haut niveau?
    
    Si par gestion automatique de mémoire tu entends "libérer la mémoire quand on sort du scope", alors oui forcément, a ce compte la, le C++ est garbage collecté...
    
    Quant a std::allocator, je cherche, mais je ne vois vraiment pas ce qu'il vient faire la. A ma connaissance, non, new n'utilise pas std::allocator, et on ne peut pas reimplementer new comme on veut en C++ (dites-moi si je me trompe).
    
    Quand a dire que mon microbench n'a aucun valeur eh bien.. il a aussi peu de valeur que n'importe quel microbench: il teste effectivement l'implementation GNU g++ 4.3 du C++ contre GNU gcc 4.3 du ooc/C avec le Boehm GC v7.1 sous Gentoo Linux en ce qui concerne l'allocation d'objets et leur destruction. Cependant, c'est représentatif des performances qu'obtiendront les utilisateurs d'un de ces langages "out-of-the-box". Je pense qu'il est donc tout de même digne d'intérêt.
    - [^]Re: Rapidité du C ... et ramasse-miettes ?
      
      Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:14. (lien). Évalué à 0.
      Tiens ben d'ailleurs, je me trompe, donc je me corrige: on peut overloader new en C++.
      Voir: [http://www.bearcave.com/software/c++_mem.html]
      
      En revanche, je vous met au défi d'implémenter un memory allocator meilleur que celui de votre implémentation C++ par défaut.
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 21:24. (lien). Évalué à 2.
        C++ ne fournit aucun "memory allocator" de son propre cru.
        
        L' "operator new" fourni par C++ n'est qu'une enveloppe autour de la routine malloc() fournie par le système d'exploitation. C'est exactement la même chose que malloc().
        
        Alors ensuite oui on peut surcharger "operator new", oui l'une des utilisations est d'avoir un allocateur de mémoire spécialisé, quoique c'est loin d'être la seule utilisation. Moi par exemple je l'utilise surtout pour avoir un "new" qui renvoie des pointeurs alignés sur 128 bits pour des données traitées par des instructions SIMD.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:00. (lien). Évalué à 2.
        Pour avoir un élément de comparaison valide, j'ai manuellement modifié le code C produit par ooc pour enlever toute référence au garbage collector, c'est a dire supprimer les appels a GC_init, remplacer les appels a GC_malloc() par malloc(), et ajouter free().
        
        Et comme on pouvait s'y attendre.... ooc est quand meme plus rapide que C++.
        Je suppose qu'on peut en déduire qu'ooc implémente les classes de manière plus légère que le C++, mais je vous laisse vous faire votre propre conclusion.
        
        Résultats:
        tsubaka ooc_tmp # time ../../withgc/newbench_cxx_O1 real 0m7.903s user 0m7.829s sys 0m0.008s tsubaka ooc_tmp # time ./newbench_O1_nogc real 0m6.427s user 0m6.309s sys 0m0.008s tsubaka ooc_tmp # time ../../withgc/newbench_cxx_O2 real 0m6.847s user 0m6.737s sys 0m0.004s tsubaka ooc_tmp # time ./newbench_O2_nogc real 0m5.976s user 0m5.855s sys 0m0.002s
        
        Code C généré par ooc avant modification (utilise le GC): http://ooc.pastebin.com/m1a579233
        
        Code C généré par ooc après modification (utilise malloc/free): http://ooc.pastebin.com/m48d21e05
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Pierre Bourdon (Jabber id, ) le 26/06/2009 à 22:10. (lien). Évalué à 2.
        Et avec g++ -O2 -fno-rtti -fno-exceptions ? D'après le code assembleur ça devrait être presque identique.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:28. (lien). Évalué à 1.
        En théorie, je suis assez d'accord. En pratique par contre, ça te (nous) contredit et j'avoue que ça me surprend moi-même.
        
        tsubaka ooc_tmp_nogc # time ../../withgc/newbench_cxx_O1_nono real 0m8.151s user 0m8.134s sys 0m0.011s tsubaka ooc_tmp_nogc # time ./newbench_O1_nogc real 0m7.125s user 0m6.999s sys 0m0.005s tsubaka ooc_tmp_nogc # time ../../withgc/newbench_cxx_O2_nono real 0m6.684s user 0m6.609s sys 0m0.046s tsubaka ooc_tmp_nogc # time ./newbench_O2_nogc real 0m5.954s user 0m5.823s sys 0m0.042s
        
        En passant, si d'autres personnes pouvaient faire tourner ces benchmarks sur leur machine, histoire de confirmer/infirmer les résultats, ça serait vraiment sympa.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par pasBill pasGates () le 26/06/2009 à 22:25. (lien). Évalué à 3.
        Moi je te propose d'ecrire un truc legerement plus realiste qu'un micro-benchmark.
        
        Une fois que tu auras fait cela et aura montre les resultats, je commencerai peut-etre a prendre tes dire sur les perfs d'ooc au serieux...
        
        Les micro-benchmarks ne montrent rien du tout, car il y a tout un tas d'elements qui entrent en compte (granularite de la heap utilisee, gestion des alignements, etc...) qui font qu'ils ne signifient absolument rien dans le monde reel.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:33. (lien). Évalué à 1.
        Tu propose d'écrire un vrai benchmark? Bien volontiers =) Envoie-moi les sources quand tu auras fini.
        
        J'ai déjà moi-même dit et répété qu'un micro-benchmark ne voulait pas dire grand-chose. En revanche, celui-la est intéressant, puisque (en tout cas dans ses dernieres incarnations) il mesure juste la différence de surpoids (overhead) entre ooc et C++ dans l'implémentation des classes.
        
        Ensuite, en ce qui concerne la granularité de la heap et la gestion des alignement, je ne suis pas du tout spécialiste dans ce domaine, mais il me semble que GNU G++ et GNU GCC ne devraient pas gérer les choses trop différemment, non? (même backend..)
        
        Je rappelle au grand public que le compilateur ooc génère du C ensuite compilé par GCC. Je pense qu'on peut donc considérer ces derniers micro-benchmarks comme des combats "à la loyale".
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par LupusMic (page perso, ) le 26/06/2009 à 21:47. (lien). Évalué à 1.
        Je n'ai pas le niveau, j'en ai conscience. Mais certains ont dû le faire : http://blog.pavlov.net/2007/11/10/memory-fragmentation/
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 23:36. (lien). Évalué à 1.
        Hum il me semble qu'ils en parlent au conditionnel, là, non?
        
        "As as last resort, we could replace malloc and new entirely with something more generally better. I don’t think we should do this until we've done as much of the other things as possible."
- [^]Re: Rapidité du C ... et ramasse-miettes ?
  
  Posté par Benoit Jacob (page perso, ) le 26/06/2009 à 21:08. (lien). Évalué à 1.
  On ne parle pas de la même chose.
  
  Bien sûr que l'on peut trouver des cas où avoir un GC améliore les performances. Dans ces cas-là on peut aussi utiliser un GC en C ou en C++: c'est quelque chose qui peut être fourni par une librarie, quoique bien entendu l'utilisation d'un GC fourni par une librarie ne soit pas aussi transparente que si le GC est fourni par le langage lui-même.
  
  En revanche, si l'on utilise un langage qui utilise automatiquement un GC, alors on est coincé: pour certaines utilisations, il peut n'y avoir aucun moyen d'obtenir un niveau optimal de performances et d'utilisation de la mémoire.
  
  Plus généralement il y a une différence de fond entre d'une part les langages qui laissent le programmeur coder "octet par octet de code machine", sans que le compilateur se permette de rajouter des opcodes à droite à gauche --- c'est le cas de l'assembleur, du C, et de l'essentiel du C++ --- et d'autre part les langages qui vont rajouter leur sauce pour simplifier la vie du programmeur dans "99% des cas" tout en rendant sous-optimal le 1% restant.
  - [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 21:20. (lien). Évalué à 1.
    Après, toute la question est: est-ce que parce que tel ou tel programme, sous telle charge de travail, tourne 2% moins vite qu'une "implémentation optimale" (au passage, tu me donneras l'URL d'une "implémentation optimale" de n'importe quel programme, parce que moi, je n'en ai jamais vu), c'est terriblement dramatique et ça va provoquer la chute en bourse de la boîte pour laquelle tu codes.
    
    En revanche, plusieurs parmi les gourous du développement s'accordent pour dire que le temps de développement requis pour un programme dans un certain programme est plus significatif qu'une faible différence de performance. Voir: [http://www.paulgraham.com/langdes.html] (en particulier la section "Speed comes from profilers", mais tout l'essai est tres intéressant)
- [^]Re: Rapidité du C ... et ramasse-miettes ?
  
  Posté par GeneralZod () le 27/06/2009 à 09:12. (lien). Évalué à 2.
  > Sur un test réalisé par curiosité, la création de 1'000'000+ petits objets dans une boucle est environ 2x plus rapide en ooc qu'en C++
  
  ça montre surtout que l'allocateur mémoire par défaut de ton implémentation de C++ est une bouse pour allouer des petits objets. C'est normal, l'allocateur par défaut doit répondre à diverses problèmatiques sans (trop) sacrifier au niveau des performances.
  Le ramasse-miette, la plupart du temps, alloue un pool mémoire au démarrage, il ne rend pas toujours la mémoire libéré par le programme, il peut utiliser différentes politiques, etc.
  Certes, ça abaisse le niveau d'entrée pour les développeurs : c'est plus simple, plus efficace et surtout plus sûr que si ils géraient manuellement la mémoire mais ça a un surcoût parfois non négligeable (ie: machine limitée en mémoire)
  
  Après, rien n'empêche le développeur C++ de programmer son propre allocateur mémoire (ce qui arrive très souvent en embarqué ou en programmation temps réel) pour améliorer les performances d'allocation mémoire. Mais pour le côté sûreté et simplicité des garbages collector, les dialectes C++ modernes offre des alternatives tout aussi bien sans surcoût: RAII, pointeurs intelligents avec ou sans comptage de référence, conteneurs etc ...
  On n'est pas obligé de choisir entre la gestion manuelle ou automatique de la mémoire, on peut s'orienter vers une gestion semi-automatique comme en C++ ou en Objective-C qui constitue un excellent compromis.
  
  Intrinsèquement, un ramasse miette n'est ni plus lent ni plus rapide qu'une gestion manuelle de la mémoire, ça dépends de la configuration (bcp d'allocations, petits/gros objets, ressources disponibles), ça dépends du développeur (niveau, envie de gérer la mémoire ou pas), du temps alloué au projet, du public visé etc ...
- [^]Re: Rapidité du C ... et ramasse-miettes ?
  
  Posté par Damien (page perso, ) le 27/06/2009 à 21:14. (lien). Évalué à 1.
  Je suis avec toi sur les performances des GC modernes, mais pourquoi en prendre un conservatif alors que puisque tu conçois le langage, tu pouvais en faire un parfait (il sait exactement ce qui est un pointeur ou pas) ?
  - [^]Re: Rapidité du C ... et ramasse-miettes ?
    
    Posté par GeneralZod () le 28/06/2009 à 12:57. (lien). Évalué à 4.
    Ce n'est que mon avis mais c'est pas un peu tôt pour se lancer dans le développement d'un nouveau ramasse-miette ?
    Boehm GC est utilisé par bon nombre de projets (GCJ, Mono, Mozilla, LLVM etc ...) qui garantit que le code a été intensivement testé et déverminé et sur un nombre important de plateformes.
    Un nouveau ramasse-miette signifierait moins de temps pour faire avancer un langage encore très jeune, essuyer pas mal de platre. Un ramasse-miette à la fois portable, performant et bien déverminé, ça demande du temps. Plus encore, si il doit être plus complexe.
    Laissons le projet avancer à son rythme, si le Boehm GC pose problème à l'évolution du langage, ce sera toujours le moment de se poser la question.
    - [^]Re: Rapidité du C ... et ramasse-miettes ?
      
      Posté par briaeros007 () le 29/06/2009 à 14:14. (lien). Évalué à 1.
      Boehm GC est utilisé par bon nombre de projets (GCJ, Mono, Mozilla, LLVM etc ...) qui garantit que le code a été intensivement testé et déverminé et sur un nombre important de plateformes.
      Ahahaha la bonne blague. Ca garantie juste qu'il est utilisé, ni plus, ni moins.
      
      J'avais fait un test tout con :
      tu prend boehm gc, tu t'amuse a créer n threads, chacun créant m objets.
      pour n et m relativement grand (style n=1000 , m=100) , en 2005, ca segfaulter.
      
      même test en allocation "a la mano"
      ca passait sans problème.
      
      --
      Subete ga wakatta toki…watashi ga anta wo korosu.
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par J A-G () le 29/06/2009 à 16:23. (lien). Évalué à 2.
        Tu ne serais pas en train de d'insinuer qu'un logiciel puisse avoir des comportements non souhaités ?
        
        Parti comme ça, tu vas aussi dire que le père Noël n'existe pas !
        
        A d'autres !!!!
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 29/06/2009 à 17:10. (lien). Évalué à 1.
        Bonne démonstration d'un test où un GC n'est pas à son avantage.
        
        As-tu testé avec la version parallelisée du Boehm GC [http://www.hpl.hp.com/personal/Hans_Boehm/gc/#multiprocessor(...)]
        
        Pour ma part je n'ai jamais eu de segfault que j'ai pu incriminer au GC. Au pire, il affiche des warnings quand on alloue beaucoup d'objets énormes souvent. C'est un comportement assez acceptable, je trouve.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par briaeros007 () le 30/06/2009 à 13:38. (lien). Évalué à 2.
        j'ai pas testé avec la version parallélisé. C'était lors d'un test avec mono et des threads (faire fonctionner mono avec une autre lib de thread), et je ne l'avais pas trouvé cette version
        
        j'ai fait un test très simple ou il n'y avait que du C, et gc, donc c'était soit le compilo, soit gc ;)
        
        --
        Subete ga wakatta toki…watashi ga anta wo korosu.
      - [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par GeneralZod () le 29/06/2009 à 18:27. (lien). Évalué à 4.
        > Ahahaha la bonne blague. Ca garantie juste qu'il est utilisé, ni plus, ni moins.
        Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
        
        Quant au côté multiplateforme, prenons le cas de Mono. Mono compile sur de multiples plateformes matérielles x86, ppc (wii, ps3 y compris), sparc, alpha, arm (iPhone), et autant d'OS: linux, BSD, Solaris, HP-UX, OS X, merdows et partout, ils utilisent Boehm GC. Si ce n'est pas une belle preuve de portabilité, etc ...
        
        > tu prend boehm gc, tu t'amuse a créer n threads, chacun créant m objets.
        Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
        
        http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par briaeros007 () le 30/06/2009 à 13:40. (lien). Évalué à 2.
        Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
        Ce qui n'a rien a voir avec "intensivement testé".
        
        Ils ont été fortement testé dans un contexte bien particulier.
        Tu sors de ce contexte, et pouf, un monde incroyable de nouveau bug s'ouvre a toi.
        
        Quant au côté multiplateforme, prenons le cas de Mono. Mono compile sur de multiples plateformes matérielles x86, ppc (wii, ps3 y compris), sparc, alpha, arm (iPhone), et autant d'OS: linux, BSD, Solaris, HP-UX, OS X, merdows et partout, ils utilisent Boehm GC. Si ce n'est pas une belle preuve de portabilité, etc ...
        Je parlais du fait qu'il ait été intensivement testé.
        Ensuite la portabilité ... ben suffit de pas utilisé des librairies spécifiques (winsock par ex) et c'est d'un coup plus simple.
        
        Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
        Pour un truc "intensivement testé" et donc "deverminé", c'est un peu opposé a "supporte meme pas les threads".
        Pourquoi il n'est pas thread safe avec les options de compilation de base ? Il faut se taper l'ensemble de la doc sur le ternet pour trouver quelque chose ?
        
        quant a ton boehm "thread safe" , de base:
        1. It causes the garbage collector to stop all other threads when it needs to see a consistent memory state.
        2. It causes the collector to acquire a lock around essentially all allocation and garbage collection activity.
        
        Trop génial : un lock global.
        Ah non, y'a pas a dire, trop top génial gc... completement testé.
        Le coup du lock global d'un coup c'est plus simple, mais c'est pas ce que j'appelle quelque chose de finalisé, ni efficace
        
        Quant aux autres options indiqués, tu m'excusera, elle semble d'un coup vachement moins "intensivement testé" ...
        
        Ah il est peut etre genial, j'ai vu qu'il avait un gc 7.0 ...
        C'est bien, et c'est quoi la différence avec gc 6.0 ? 6.7 ?
        
        Gc est peut etre génial, avec une tonne d'option de compilation, de define qui font même le café, mais tu m'excusera, avec une doc comme ça...
        
        --
        Subete ga wakatta toki…watashi ga anta wo korosu.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 30/06/2009 à 16:33. (lien). Évalué à 1.
        "pas thread-safe" n'a jamais été un bug.
        "être thread-safe" détériore la performance dans un environnement monoprocessus. D'où l'intérêt de ne pas l'être.
        
        > la portabilité.. suffit de pas utiliser de libraries comme winsock
        Hum. Voilà une remarque de quelqu'un qui n'a pas vu assez de #ifdef dans sa vie.
        Sérieusement, faire une librairie C bas-niveau portable c'est juste un exploit sans cesse renouvelé.
        
        Mais bon si c'est si facile hein vas-y code un meilleur GC, je serais le premier utilisateur.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par imalip (page perso, ) le 30/06/2009 à 17:57. (lien). Évalué à 3.
        Hum. Voilà une remarque de quelqu'un qui n'a pas vu assez de #ifdef dans sa vie.
        
        Ou alors de quelqu'un qui en a deja vu beaucoup trop...
        
        --
        "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par briaeros007 () le 02/07/2009 à 09:08. (lien). Évalué à 1.
        "pas thread-safe" n'a jamais été un bug.
        Si tu estime que les race conditions ne sont pas des bugs...
        
        "être thread-safe" détériore la performance dans un environnement monoprocessus. D'où l'intérêt de ne pas l'être.
        1°) ce n'est pas toujours vrai
        2°) y'a des méthodes pour faire en sorte que la détérioration soit minimale
        3°) la vérification des codes de retour et la gestion des erreurs détériore aussi la performance, d'où l'intérêt de ne pas faire de gestion d'erreur ?
        Marrant j'ai pas la même conception.
        
        Sérieusement, faire une librairie C bas-niveau portable c'est juste un exploit sans cesse renouvelé.
        Un exploit rien que ça.
        Si on vire un certain os qui est infoutu de respecter la moindre norme, c'est d'un coup plus facile. :P
        
        Mais bon si c'est si facile hein vas-y code un meilleur GC, je serais le premier utilisateur.
        Alors tu sors "il est super G, super testé super stable toussa".
        J'ose dire "euh non, pas super g, et si on teste franchement les threads alors ca merde".
        Et ta réponse "non mais tu as qu'a la coder".
        
        Mais j'en ai RIEN A FOUTRE de coder un gc, moi je l'utilise pas!
        Et puis j'ai jamais dis que c'était facile. J'ai juste osé dire que tout n'était pas parfait au pays des gc.
        Si tu n'es pas foutu d'accepter ça....
        
        --
        Subete ga wakatta toki…watashi ga anta wo korosu.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 03/07/2009 à 12:40. (lien). Évalué à 1.
        For the record, c'est pas moi qui ai dit que Boehm GC était super testé/stable, ce qui est pourtant vrai.
        
        Et par contre personne ici n'a jamais dit que tout était parfait au pays des GC. Pour ma part, c'est juste un des compromis existants qui me satisfait.
        
        Pour ce qui est d'être thread safe, je persiste et signe, non, pour une application/librairie clairement designée pour tourner en monoprocessus seulement, ne pas être thread-safe "is not a bug, it's a feature".
        
        Pour le parallèle, il y a d'autres projets, voir le lien de Sébastien Binet ci-dessous.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Sebastien Binet () le 30/06/2009 à 19:22. (lien). Évalué à 2.
        pour info, un projet de GC concurrent:
        
        http://code.google.com/p/scarcity/
        
        il devrait être utilise a terme par python (unladen-swallow)
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par GeneralZod () le 30/06/2009 à 19:35. (lien). Évalué à 2.
        Pour clarifier un peu les choses (Pour ceux qui n'ont pas suivi), unladen-swallow c'est l'implémentation Python de Google basé sur LLVM.
        Effectivement, scarcity devrait être utilisé comme GC pour unladen-swallow mais étant écrit en C++, il est improbable qu'il soit inclut dans CPython.
        
        PS: d'après Google, unladen-swallow est plus un fork "temporaire" de CPython qu'une implémentation distincte, en outre, unladen-swallow vise la compatibilité source avec CPython et ses extensions.
        http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par djano () le 01/07/2009 à 15:07. (lien). Évalué à 0.
        Bah tu sais ce qu'on dit sur linuxfr.org, si tu peux faire mieux tout le monde sera content et tu auras toute la reconnaissance de plein de gens. Maintenant ça passe par la case code...
        
        Sérieusement, Boehm gc a commencé comme étant not thread safe et il l'est encore. La belle affaire! Ta critique n'est pas bien utile. Critiquer un gc sur le fait qu'il n'est pas thread safe alors que cela est connu n'apporte rien.
        
        Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
        Ce qui n'a rien a voir avec «intensivement testé».
        Les tests ne testent que ce pour quoi on les écrit si on dit que le GC est pas thread-safe pourquoi écrire des tests pour montrer qu'il ne l'est pas? hmm?
        
        Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
        Pour un truc «intensivement testé» et donc «deverminé», c'est un peu opposé a «supporte meme pas les threads».
        Je vois pas le rapport.
        
        Trop génial : un lock global.
        Ah non, y'a pas a dire, trop top génial gc... completement testé.
        Le coup du lock global d'un coup c'est plus simple, mais c'est pas ce que j'appelle quelque chose de finalisé, ni efficace
        Ahem Python a aussi un lock global. Linux, FreeBSD avaient un lock global jusqu'à récemment. Pourtant ils étaient déjà utilisé en production mais pas finalisés selon toi? Il faut croire que tout le monde ne voit pas les choses de la même manière que toi.
        
        M'enfin si ça t'amuse continue a critiquer dans le vent.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par briaeros007 () le 02/07/2009 à 09:19. (lien). Évalué à 1.
        Maintenant ça passe par la case code...
        Ah le fameux "si tu code pas, tu peux pas critiquer", histoire de bien se cacher les yeux et expliquer ensuite ce que l'utilisateur veux.
        
        Alors je le redis JE RECODERAIS PAS GC, ET JE CONTINUERAIS A DIRE QU'IL A DES MERDES tant qu'il en auras.
        
        Et si tu n'es pas content, ben c'est ton problème.
        
        Sérieusement, Boehm gc a commencé comme étant not thread safe et il l'est encore. La belle affaire! Ta critique n'est pas bien utile.
        Comme 30 poste pour dire "you want it you code it. You're juste a looser. Developer of gc are god".
        
        Critiquer un gc sur le fait qu'il n'est pas thread safe alors que cela est connu n'apporte rien.
        1°) si : indiquer qu'il n'est pas thread-safe
        2°) l'information qu'il n'est pas thread-safe, contrairement a ce que tu affirme, n'est pas si "connu que ça".
        De toute façon, tu as vu la page de gc ? Et tu ose me tenir rigueur du fait que leurs trucs sont mal expliqué ?
        J'ai vu des sources de la version 7, et les tests et ajouts que j'ai vu sur le site officiel concernait la version 6...
        faut faire quoi ? écumer google
        
        Les tests ne testent que ce pour quoi on les écrit si on dit que le GC est pas thread-safe pourquoi écrire des tests pour montrer qu'il ne l'est pas? hmm?
        Ne pas dire qu'il est super stable si il n'est pas thread-safe.
        
        Je vois pas le rapport.
        Moi si.
        
        Ahem Python a aussi un lock global.
        On parlait de gc ou de python ?
        
        Linux, FreeBSD avaient un lock global jusqu'à récemment.
        On parlait de gc ou de linux ?
        et atha , le "jusqu'à récemment" ... pourquoi l'ont ils enlevé ? Parce que c'était la meilleure solution le lock globale.
        
        Sans compter que comparer un gc a un noyau est relativement comique.
        
        Il faut croire que tout le monde ne voit pas les choses de la même manière que toi.
        Voui c'est clair. D'ailleurs sous linux ils comptent mettre un autre gros lock global une fois qu'ils auront réussi a enlever le précédent, parce que c'est une solution technique tellement elegante et efficiente....
        
        M'enfin si ça t'amuse continue a critiquer dans le vent.
        Quant tu devra coder des applis parallèles, performantes, avec un framework qui utilise gc, on verras si tu estimeras encore que c'est "dans le vent" quant tu auras un bon gros bug au milieu, et que tu est obligé de perdre une semaine a trouver que c'est le gc qui merde.
        
        --
        Subete ga wakatta toki…watashi ga anta wo korosu.
        
        [^]Re: Rapidité du C ... et ramasse-miettes ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 03/07/2009 à 12:42. (lien). Évalué à 1.
        Si tu dois passer une semaine à te rendre compte par l'échec de ton appli que le GC que tu utilises n'est pas parallèle, eh bien... RTFM.

Ramasse-miette conservatif..

Posté par reno () le 26/06/2009 à 20:42. (lien). Évalué à 2.

Juste pour ceux qui ne saurait pas, un ramasse-miette conservatif peut avoir des inconvénients: certaines données peuvent etre confondue avec des pointeurs et le résultat est que certains programmes *correctes* consomment des quantité de mémoire excessive (probleme existant surtout en mode 32bit).

Ce n'est pas qu'un probleme théorique: j'ai vu plusieurs message sur le newsgroup de D d'utilisateurs qui se plaignaient d'une consommation excessive de mémoire qui était tombé dans ce cas la (D utilise aussi le Boehm GC).

L'avantage du ramasse miette Boehm est qu'il est mature et fonctionne avec du C (enfin si le C n'est pas trop crade: pointeur XOR-és: aucun GC ne peut traiter cela pourtant c'est possible en C) mais cela n'en fait pas (et de loin) le top au niveau ramasse-miette..

Je pense notamment qu'il ne doit pas etre tres temps reels (meme s'il est incrémental d'après wikipedia).

[^]Re: Ramasse-miette conservatif..

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 20:48. (lien). Évalué à 1.
J'avoue, utiliser le Boehm GC était a l'époque de cette décision, une solution de facilité. Pour la prochaine implémentation (voir [http://github.com/amoswenger/rock]), je considère sérieusement d'écrire un GC non-conservatif (puisque plus le temps passe, plus ooc est strictement typé.)

Pour ce qui est de l'usage d'un gc (peu importe lequel) en temps réel, je n'ai jamais entendu/vu ça. URL, please.
- [^]Re: Ramasse-miette conservatif..
  
  Posté par reno () le 27/06/2009 à 13:33. (lien). Évalué à 3.
  Voici un lien qui parle d'un GC compatible avec le temps réel vendu par IBM (MetroNome):
  http://lambda-the-ultimate.org/node/2034
  
  Le seul language avec une implementation libre que je connais avec un GC temps reel est SuperCollider:
  http://supercollider.sourceforge.net//
  
  Comme autre ammélioration possible: un GC qui 'interagit' avec le systeme de mémoire virtuel d'un OS (nécéssite qu'il soit modifié en conséquence donc pas utilisé a l'heure actuel) pour reduire les conséquence qu'une fuite mémoire a avec un GC classique:
  http://lambda-the-ultimate.org/node/2391
  - [^]Re: Ramasse-miette conservatif..
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 16:24. (lien). Évalué à 1.
    Merci pour les liens!
    
    Malheureusement, de ce que je peux voir, il n'y a pas grand chose d'utilisable "out-of-the-box". On va dire que pour l'instant, comme GC, le Boehm me va assez bien je trouve.
    - [^]Re: Ramasse-miette conservatif..
      
      Posté par reno () le 27/06/2009 à 22:56. (lien). Évalué à 1.
      Le GC temps réel de la JVM d'IBM est propriétaire oui, mais l'implementation de SuperCollider est GPL.
      
      Et pour le GC qui coopère avec la mémoire virtuelle j'ignore si l'auteur en a fait une implémentation libre mais de toute manière ses patches pour le noyau Linux ont été rejeté, ce GC n'est donc pas utilisable actuellement en effet.

Compatibilité avec les lib C++ ?

Posté par 0xFF () le 26/06/2009 à 21:37. (lien). Évalué à 2.

Tous ces nouveaux langages compilés (Ocalm, D, ooc...) semble très prometteurs. Je n'ai pas encore eu l'occasion de les tester mais ça m'intéresse beaucoup. Mais qu'en est-il de leur compatibilité avec les API faite en C++ ? Est il possible, et facile, d'utiliser des lib C++ avec ooc ? Je supose que non puisque que je n'ai rien vu dans la doc qui en parle. Mais malheureusement j'utilise presque uniquement des API faite en C++ dans mes projets.

Est-ce que c'est impossible de marier les deux ?

[^]Re: Compatibilité avec les lib C++ ?

Posté par Pierre Bourdon (Jabber id, ) le 26/06/2009 à 21:43. (lien). Évalué à 1.
Je ne connais pas ooc ni D, mais je sais juste qu'en OCaml c'est vraiment la merde de binder des libs C++ pour les utiliser de manière bien intégrées au langage, encore plus si on veut gérer des trucs comme faire hériter des classes OCaml de classes C++. Swig y arrive plus ou moins mais en introduisant une syntaxe différence de celle d'OCaml (avec des -> au lieu de #, etc.) et avec plein de couches qui rendent le programme compilé immense et le code source illisible.

[^]Re: Compatibilité avec les lib C++ ?

Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 22:09. (lien). Évalué à 2.
Super question, merci =)

J'ai moi-meme eu ce probleme, puisque pour le projet pour lequel j'ai ecrit ooc, l'enonce encourageait a utiliser GLUI (librairie graphique d'interface utilisateur en C++). J'ai donc du me lancer dans les joies de la compilation jointe de code C et C++ (sans avoir son main dans un .cxx), et c'est horrible. Et j'ai du écrire toutes les méthodes à la main.

En revanche, en pratique, rien n'empêche d'améliorer le compilateur ooc pour qu'il comprenne les headers C++ et permette l'utilisation de leurs classes/fonctions. Moi c'est plus la compatibilité binaire qui m'inquiète (entre le C et le C++), parce que oui, le C++ n'a pas d'ABI standard, bien sur...

Si assez de personnes sont intéressées par l'utilisation transparente de librairies C++ en ooc, je me pencherais volontiers sur le problème, même si je préfèrerais voir fleurir des ports en ooc de librairies C++ ;)
- [^]Re: Compatibilité avec les lib C++ ?
  
  Posté par Cédric Chevalier (page perso, ) le 26/06/2009 à 23:03. (lien). Évalué à 2.
  J'ai donc du me lancer dans les joies de la compilation jointe de code C et C++ (sans avoir son main dans un .cxx), et c'est horrible.
  
  Faut arrêter quand même c'est pas du FORTRAN... Les codes mixtes C/C++ sont fréquents et cela se passe plutôt bien.
- [^]Re: Compatibilité avec les lib C++ ?
  
  Posté par LupusMic (page perso, ) le 26/06/2009 à 23:12. (lien). Évalué à 1.
  C++ a une ABI normalisée. Mais les implémentations ne la respectent pas forcément. Par exemple, GCC a migré son ABI propriétaire vers l'ABI normalisée entre 2.9 et 3.0 si mes souvenirs sont bons.
  
  Mais je ne vois pas le problème d'avoir un main dans un .c et d'utiliser une API C++. Il y a des méthodes qui permettent de facilement jongler entre les différentes unités de compilation.
  - [^]Re: Compatibilité avec les lib C++ ?
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 26/06/2009 à 23:34. (lien). Évalué à 1.
    > C++ a une ABI normalisée.
    
    Ah bon ? Faudra penser a mettre a jour Wikipédia, dans ce cas:
    
    "The C++ standard therefore does not attempt to standardise name mangling. On the contrary, the Annotated C++ Reference Manual (also known as ARM, ISBN 0-201-51459-1, section 7.2.1c) actively encourages the use of different mangling schemes to prevent linking when other aspects of the ABI, such as exception handling and virtual table layout, are incompatible."
    
    Source: [http://en.wikipedia.org/wiki/Name_mangling#Standardised_name(...)]
    
    > Mais je ne vois pas le problème d'avoir un main dans un .c et d'utiliser une API C++. Il y a des méthodes qui permettent de facilement jongler entre les différentes unités de compilation.
    
    Ma foi c'est bien possible qu'à l'époque je m'y sois mal pris. De toute façon j'ai vite abandonné GLUI (beurk) pour faire mon appli en GTK+/gtkglarea.
    - [^]Re: Compatibilité avec les lib C++ ?
      
      Posté par LupusMic (page perso, ) le 27/06/2009 à 00:56. (lien). Évalué à 1.
      Ah ben en fait j'avais mal compris à l'époque : http://gcc.gnu.org/gcc-3.2/c++-abi.html
      
      Il y a donc un effort de standardisation entre les différents compilateurs, sans avoir de norme établie. Cela me rend perplexe quand au fonctionnement de programmes compilés avec gcc sous MS Windows, utilisant des bibliothèques compilées avec le compilateur C++ de Microsoft. Il doit bien y avoir une compatibilité binaire.
      - [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 02:04. (lien). Évalué à 1.
        A mon humble avis, les interfaces des librairies dynamiques (.dll) sont standardisées, donc pas de souci. Par contre, compiler statiquement un programme sous MinGW/gcc avec des objets binaires provenant de deux compilateurs différents.. eh ben j'ai jamais testé mais ça doit pas être joli :/
        
        [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Zenitram (page perso, ) le 27/06/2009 à 14:27. (lien). Évalué à 2.
        A mon humble avis, les interfaces des librairies dynamiques (.dll) sont standardisées, donc pas de souci.
        
        C'est standardisé en C, pas en C++.
        En C, tu peux faire communiquer une appli et une DLL quelque soit le compilo de chacun en forçant le typage par le langage
        En C++, le mangling merde, et donc il faut le même compilo (la même marque).
        
        Quand aux libs statiques, effectivement c'est encore plus la merde!
        
        [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 16:25. (lien). Évalué à 1.
        C'bien ce qui me semblait, mais alors justement d'ou la question plus haut:
        Cela me rend perplexe quand au fonctionnement de programmes compilés avec gcc sous MS Windows, utilisant des bibliothèques compilées avec le compilateur C++ de Microsoft.
        
        [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Zenitram (page perso, ) le 27/06/2009 à 17:30. (lien). Évalué à 3.
        l'API Windows est en C, donc compatible.
        Et la plupart des DLL proposent une API en C (quitte à faire un binding C vers C++ en interne, ce que je fais par exemple).
        
        [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 17:48. (lien). Évalué à 1.
        Merci pour les éclaircissements, mais je suis déçu, j'avais naïvement supposé qu'ils avaient inventé une astuce super duper pratique.
        Puisqu'on finit toujours par en revenir au C, pourquoi ne pas partir du C tout court..
      - [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Troy McClure (page perso, ) le 27/06/2009 à 11:57. (lien). Évalué à 2.
        il y a compatibilité sur les fonction "C". Pour tout ce qui est c++, 0 compatibilité le name-mangling the gcc et msvc n'ont rien à voir (ainsi que la gestion des exceptions, etc)
- [^]Re: Compatibilité avec les lib C++ ?
  
  Posté par 0xFF () le 27/06/2009 à 00:01. (lien). Évalué à 1.
  Pouvoir utiliser des libs C++ avec ooc sans avoir besoin d'écrire un binding ou autre chose ce serai génial. Écrire un binding pour une lib c'est quand même un travail très fastidieux. Dans le cas d'une lib avec une grosse API (comme une lib d'interface graphique ou un moteur 3D) rien que de réécrire tous les headers peut rendre fou !
  Je pense que la possibilité d'instancier et d'utiliser des objets C++ dans ooc serait suffisante. Hériter des classes C++ en ooc ne me semble pas du tout indispensable (d'ailleurs ça me semble même dangereux). Ne parlons même pas des templates qui n'ont rien à faire en dehors du code C++ :)
  Après, je ne sais pas dans quel mesure cela est faisable. Mais je serais attentif aux évolutions de ooc.
  - [^]Re: Compatibilité avec les lib C++ ?
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 00:44. (lien). Évalué à 1.
    Eh bien je m'y attaquerais, alors. Parser du C++, c'est un cauchemar, mais pour pouvoir utiliser une lib C++ il suffit de pouvoir parser ses headers (c'est ce qui se passe avec les librairies C avec ooc pour l'instant).
    Je donnerais donc des nouvelles a propos du support des librairies C++ sur le blog, probablement.
    - [^]Re: Compatibilité avec les lib C++ ?
      
      Posté par mosfet () le 27/06/2009 à 15:47. (lien). Évalué à 1.
      C'est un doux reve de vouloir supporter les libs C++, les ABI ne sont pas compatibles entre compilateur.
      Ceci dit une citation pour me contredire :
      
      Ils ne savaient pas que c'etait impossible. Alors ils l'ont fait
      - [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 16:36. (lien). Évalué à 1.
        Eh bah justement, motus et bouche cousue, qui sait, peut-être quelqu'un (moi ou un autre) le fera.
        
        Et puis bon, moi avec une page comme ça, je suis comblé et j'suis assez grand pour implémenter tous leur algorithmes de Name mangling incompatibles pourris : http://en.wikipedia.org/wiki/Name_mangling#How_different_com(...)
        
        Et si ça suffit pas, eh ben le reste des différences est ajustable aussi (oui ça va créer du code C spécifique à un compilateur C++, mais personne a dit que tout ce qui était pratique était nécessairement propre). Ce qui est très fastidieux (voir impossible) à faire quand on a à le faire à la main, peut devenir au moins possible, voire même très accessible, quand on a tous les éléments en main pour l'automatiser (=qu'on modifie son propre compilateur.)
        
        En l'occurence pour parser les headers C++ (qui ne sont tout de meme pas une partie de plaisir), j'avais pensé a Elsa: [http://www.eecs.berkeley.edu/~smcpeak/elkhound/sources/elsa/] Et puis finalement je pense réécrire le front-end du compilateur ooc + un parser de headers C/C++ avec ASF+SDF [http://www.meta-environment.org/] et ça, ça a l'air sacrément puissant et ça génère des APIs en Java et C (donc utilisable aussi pour rock, réécriture du compilateur ooc en ooc lui-même.)
        
        Bref, ne crions pas défaite trop vite non plus. (Et pis si c'était pas impossible, y'aurait aucun fun, non?)
        
        [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par 0xFF () le 27/06/2009 à 17:53. (lien). Évalué à 1.
        Je ne comprend pas le problème (mais je n'y connais pas grand chose au fonctionnement des compilateurs, c'est pour ça). Quand je fait un programme en C++, je choisit les libs qui sont compatibles avec le compilo que j'utilise. Et d'après ce que j'ai compris, ooc me permet de choisir le compilateur que je veux utiliser. Donc si je dit a ooc d'utiliser tel compilo et que j'utilise des libs qui marchent avec ce compilo, ça doit marcher tout seul non ?
        Je m'excuse par avance dans le cas ou j'aurais dit une grosse bêtise...
        
        [^]Re: Compatibilité avec les lib C++ ?
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 18:02. (lien). Évalué à 1.
        Ce n'est pas une grosse bêtise du tout =)
        
        Le seul problème potentiel avec ça que je voyais c'est que les compilateurs C++ sont méchamment plus stricts au niveau des casts que les compilateurs C. (Donc non, le C++ n'est pas un superset du C compatible), donc il faudrait que je modifie le générateur de code pour qu'il rajoute des casts partout ou il faut, afin que les compialteurs C++ ne pleurent plus.
        
        Alors qu'avec l'approche que je propose, ooc ferait un petit bout du boulot qu'un compilateur C++ ferait (principalement le name mangling) et enverrait tout ça au compilateur C, qui serait très content puisqu'il trouverait les bons symboles (ex. noms de fonctions) dans les librairies C++ avec lesquelles on lui demande de linker.
        
        (puristes: oui le compilateur ne linke pas, mais je prend des raccourcis pour être plus compréhensible)

Critique du langage.

Posté par LupusMic (page perso, ) le 27/06/2009 à 00:46. (lien). Évalué à 2.

Je ne suis pas un guru de la programmation, mais je pense pouvoir te fournir quelques remarques qui te permettrons d'améliorer ton langage.

Pour l'ensemble de mes remarques, je vais suivre et commenter le ninja language reference http://ooc-lang.org/doc/langref/book1.htm (tu devrais rajouter dans la FAQ pourquoi c'est une référence Ninja).

http://ooc-lang.org/doc/langref/c31.htm
« All types should be in CamelCase, all variables and functions in camelCase. [...] The justification for that is consistency. »

Je ne vois pas en quoi le nomage des « types » en Java est incohérent. Les POD ont une minuscule parce qu'ils ne sont pas des objets. Si ton système est cohérent, alors on peut dériver depuis un Int. Dans le cas contraîre, c'est OOC qui est incohérent et non Java. À noter qu'ici Java est cohérent, raison de l'existence des classes Integer, Float, etc.

Quand au C++, la tradition est de ne jamais utiliser de majuscules. Que ce soit pour les noms de classe ou des fonctions. Seules exeptions, les noms de constantes ou les nom des paramètres de templates. Par exemple : void std::map<template T>::push(T &) ;

« You can declare several variables on the same line »
Mauvaise habitude. En plus tu montre que tu ne sais pas que le type pointeur n'existe pas en C/C++ (c'est un qualificatif).

« Correspondance with C and Java types »
En Java, je crois bien qu'on peu utiliser le mot-clé « self » dans la liste des paramètres et le type de retour des fonctions membre. En C++, je déclare souvent typedef Myclass self.

Je ne comprends pas cette prolifération de types numérique. Pourquoi ne pas proposer un type générique qui gère les opérations sur les nombres avec une précision arbitraire ? Ça permettrait de totalement abstraire l'usage des nombres, ce qui manque avec C++ et Java (il faut toujours faire attention aux limites, ce qui est rarement testé correctement, voir ignoré le plus souvent).

Le nom Octet est franchement maladroit, quant on sait qu'un byte ne fait pas forcément un octet. D'ailleurs, quelle est la taille de tes int (parce qu'en C, c'est dépendant de l'architecture, tout comme char) ?

« printf("A moins que vous n'epousiez la %s?\n", name); »
Pourquoi pas :
console.print "A moins que vous n'epousiez la %s?\n".format name ;

Je n'arrive pas à entrevoir l'intérêt des Covers sur la dérivation de la classe.

http://ooc-lang.org/doc/langref/x209.htm
Une critique qu'on peut faire au C++, c'est d'avoir conserver les tableaux à la mode C. Pourquoi faire la même erreur ? L'encapsulation des tableaux permet d'éviter la duplication des tests de contrôle, et surtout t'éviter tout problème de sécurité relatif au débordement de tampon (et de centraliser la correction d'un éventuel bogue). Ton langage impose déjà plusieurs paradigme : tu devrais aller au bout de ton idée. Sinon, autant faire du C ou du C++.

« A function is declared with the func keyword. »
Pourquoi un mot-clé ?

« func add(Int arg1, Int arg2) -> Int { } »
Argh... Je n'ai jamais compris cette logique que de noyer le type de retour après la list de paramètres (Pascal, Basic, etc).

« The main function: entry point »
Mais pourquoi une fonction ? :D

« SDL_Quit(); // We must use parenthesis, cause it's a C function »
On pourrait te reprocher une certaine incohérence à ce niveau là. Mais je comprends la limitation technique.

« Instanciation »
Je ne comprends pas l'intérêt du mot-clé new. En plus, de ce que j'en comprends, tes types ne sont jamais créé sur la pile ? Dans ce cas, tu devrais reprendre ton benchmark sur l'instantiation, et faire la création sur la pile. Tu verras que la différence de performances est... non-négligeable (l'instantiation sur la pile est 7× plus rapide que dans le tas, chez moi).

Un objet peut-il être utilisé comme un functor ?

Les objets sont polymorphiques ?

Quelle est la portée par défaut des membres d'une classe ? Public ? N'est-ce pas là une violation du principe d'encapsulation ?

« for in ranges »
C'est pratique, indubitablement. Une bonne idée serait de rajouter un type Range. Pour éviter de déclarer des ensemble en dur dans les boucles. En embarquant le pas dans le Range, évidemment.

Tu aurais pu virer switch ;)

Pas de do..while ?

« The package of a source unit is relative to the sourcepath. »
Je ne penses pas que ce soit une bonne idée. Pour tout un tas de raisons, allant de la relativité du chemin au caractère dur du chemin. Bien que le mot-clé super permette de contourner partiellement ce défaut.

Voilà pour mes quelques remarques. J'espère que ça t'aidera dans ta réflexion.

[^]Re: Critique du langage.

Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 02:02. (lien). Évalué à 1.
Bonbonbon, eh bien voila plein de critiques intéressantes. Je vais reprendre point par point:

> ninja language reference
ninja est le nom de code de la version 0.2. Je devrais peut-etre mettre entre parenthese le nom complet de la version pour éviter les problèmes de priorité d'opérateurs ;)

> types primitifs en minuscule/majuscule
ca dépend de ta définition de "cohérence", en fait. comme dit dans le guide, ooc privilégie la cohérence syntaxique. Cela permet une lecture du code très facile. Tout ce qui a une majuscule en premier = un type. Tout ce qui n'en a pas = une variable ou une fonction
Pour la "tradition C++", le problème c'est que comme il n'y a aucun standard qui est forcé, tout le monde le fait a sa sauce, et a utiliser c'est un joyeux mélange.
Quant aux classes Integer/Float en Java, ce sont a mon humble avis des abominations.

> several variables on the same line
Je ne vois pas ou est-ce que j'ai dis que "pointeur" etait un type. De plus, sans les pièges du C/C++ concernant justement ce point de grammaire, la déclaration de plusieurs variables lignes n'est *plus* une mauvaise habitude, puisqu'elle est sans danger.

> correspondance with C and Java types
Le mot-clé self? Jamais entendu parler en Java. url?
pour les types numériques, il y en a peut-etre en effet plus que nécessaire.. personellement j'utilise quasiment uniquement des Int et des Float, mais c'était surtout pour ne pas décevoir les programmeurs C qui aiment avoir des types petits pour pouvoir stocker érnomément de nombres en mémoire.

Pour Octet, et bien précisément non il n'est pas maladroit ;) Le guide ne l'explicite pas assez, mais c'est un typedef vers un uint8_t qui a une taille fixe de.. 8 bits. Si "unsigned char" est aussi dans la colonne "C" a la meme ligne, c'est parce qu'il est généralement utilisé à sa place, par erreur de compréhension (donc que ceux qui utilisent des unsigned char a la place d'uint8_t devraient utiliser des Octet et non des Char en ooc.)
Les Int en revanche sont des typedefs vers int, donc ils sont également de taille variables. Je vais réfléchir a l'utilisation d'un type numérique de précision arbitraire, mais j'ai l'impression que ce serait très couteux au niveau performance, non?

> pourquoi pas console.print "A moins que vous n'epousiez la %s?\n".format name ;
la vraie question est "quand" et non "pourquoi pas" ^^ l'appel de fonctions ayant des arguments sans parentheses est prévu, et la méthode format de String aussi, cependant ça, ça attendra que je trouve une bonne manière d'implémenter/d'écrire (syntaxe) les fonctions variadiques.

> covers
ce qui a pu t'échapper, c'est qu'une Cover, c'est d'un type primitif, pas d'une classe. Rajouter des fonctions a un type primitif, et donc pouvoir l'utiliser (syntaxiquement) comme un objet, c'est l'utilité principale des covers.

> tableaux
c'est vrai que je n'y ai pas réfléchi beaucoup. Dans l'application qui m'a poussé a développer ooc, j'utilisais des structures plus avancées comme des ArrayList/SparseList, donc des routines de bas niveau encapsulées dans des classes donc avec bound checking et tout le bazar. Je ne vois aucune objection a encapsuler tous les tableaux dans des objets, de plus le cout est rellement minime (1 pointeur vers la structure de meta-classe).

> mot-clé func
1) lisibilité, 2) facilité de parsing (moins d'ambiguites dans la grammaire). Et si tu as des doutes sur la nécessité de résoudres des ambiguités qui apparamment n'existent pas, considère que j'ai prévu en ooc la possibilité de faire des fonctions imbriquées (nested functions), et des closures. Le mot-clé func permet donc d'être très lisible et clair dans tous les cas.

> type de retour après la liste des paramètres
parce que 1) en C, void ne sert a rien (sinon a faire des pointeurs sur n'importe quoi). C'est un mot parasite qui encombre la syntaxe. Avec une syntaxe comme ooc 0.2, quand tu as une liste de fonction tu vois les choses de gauche a droite dans l'ordre qui t'intéresse le plus (en général) a savoir 1) le nom de la fonction 2) les arguments qu'elle prend et 3) le type de retour s'il y en a un.

> pourquoi une fonction main?
heuuuuuuuuuuuuuu eh ben parce qu'on a toujours fait comme ça? ;) non sans rigoler, merci de me rappeler ce que je voulais faire depuis longtemps, en fait. je note.

> SDL_Quit()
en effet c'est une incohérence ET une limitation technique temporaire. La note de bas de page explique la difficulté à parser correctement certains headers C. Des améliorations sont à attendre dans les prochaines versions, of course.

> Instanciation & mot-clé new
le mot-clé new est principalement une affaire de lisibilité
Pour l'allocation sur la pile/le tas, eh bien.. pour etre franc, je me suis dit "Java alloue tout sur le tas, et les performaces sont acceptables dans la plupart des cas, donc ça ne devrait pas poser problème."

Et, après benchmarks, eh ben effectivement:
newbench_O1 6.522s newbench_O1_stack: 1.004s newbench_O2: 5.890 newbench_O2_stack: 0.867s
Je viens de me dire.. je pourrais faire en sorte, dans le compilateur, que le compilateur détecte ce qui peut etre alloué sur la pile ou le tas, suivant si la variable reste locale ou si son adresse est envoyée ailleurs pour être stockée (ex. appel de fonction avec une assignation de pointeur) ou si elle reste locale, auquel cas elle peut etre allouée sur la pile.

> functor
si tu demandes si on peut appeler un objet avec une méthode call a une fonction qui s'attend a un pointeur sur une fonction en espérant très fort que ca appelle "call" tout seul, eh bien non. Pour l'instant, ooc gère les pointeurs sur les fonctions de la même manière que le C pur, mais cela pourrait bien changer (pour permettre le passage de fonctions membres en tant que callback.) J'ai déjà testé une solution basée sur GNU lightning, qui assemble en temps réel une fonction qui appelle la fonction member sur le bon objet. Je n'ai pas fait de benchmarks de performance, par contre.

> les objets sont-ils polymorphiques ?
bien sur =) ooc n'aurait que peu d'intérêt s'ils ne l'étaient pas.

> portée par défaut et encapsulation
absolument, ooc ne gère actuellement pas les différentes portées, et c'est très très vilain de ma part (je devrais être puni). Mais de nouveau, c'est par manque de temps pour l'instant: implémenter correctement les règles d'encapsulation n'est pas du tout simple, vous pouvez trouver facilement des exemples contre-intuitifs en Java par exemple.

> for in ranges
le type range, c'est prévu ^^ de nouveau, manque de temps jusqu'ici.

> virer switch
tiens donc? pourquoi cela? je pensais juste inverser le comportement par défaut du C/C++/Java, plus précisément introduire un mot-clé fallthrough et gicler le mot-clé break pour les switch.

> do while
Tiens donc, petit oubli de ma part. Bien que je ne l'aies pas du tout prévu dans le compilateur ooc, ca compile quand meme (je viens de tester) car cela ne provoque pas d'erreur de syntaxe.

> relative to the sourcepath
eh bien c'est un point controversé en effet, je n'ai pas fini d'y réfléchir, mais j'attends encore qu'on me donne une très bonne raison pour devoir rajouter des lignes "package blah.truc.machin;" a toutes mes classes, autre que "ouais mais si c'est pas le bon sourcepath, ca va tout foirer". C'est pas des manchots, les programmeurs quand meme, ils savent encore quel sourcepath ils mettent, non?

en tout cas merci pour toutes les remarques, c'est assez curieux: pour la moitié j'ai l'impression que tu voudrais transformer ooc en python, et l'autre moitié que tu voudrais le transformer en C++! on va tenter de trouver un juste milieu =)
- [^]Re: Critique du langage.
  
  Posté par 0xFF () le 27/06/2009 à 12:26. (lien). Évalué à 2.
  Qu'en est-il de l'héritage multiple ? Est ce que ooc le supporte ou est ce qu'il va le supporter dans le futur ? Si oui de quelle façon ? Seulement un héritage multiple de classe abstraite comme en Java ? Ou un vrais héritage multiple de classes comme en C++ ?
  
  Je sais que l'héritage multiple de classes peut s'avérer très dangereux quand il n'est pas utilisé correctement, mais dans certaines situations c'est tellement pratique.
  - [^]Re: Critique du langage.
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 16:56. (lien). Évalué à 1.
    J'ai pas mal réfléchi à cette question déjà au début de la conception d'ooc, et j'ai décidé de faire un héritage à la Java: une classe parente maximum, et tu implémentes autant d'interfaces que tu veux.
    
    Pourquoi maintenir la différence entre classe et interface? Parce que dans l'implémentation courante, les casts entre sous-classes et super-classes sont quasiment gratuits, ce sont de bêtes casts C;
    abstract class Parent { abstract func call; } class Child from Parent { implement call { // blablablah. } } func doThing(Parent p) { p.call; } func main { // le fait de passer un Child au lieu d'un Parent // n'induit quasiment aucune pénalité doThing(new Child); }
    puisque les champs et les fonctions, dans leurs structures respectives, sont ordonnés dans l'ordre d'héritage (un enfant a les champs/fonctions de ses parents dans le même ordre, puis les siens, voir l'ABI "standard" ooc dans le language reference guide).
    
    Dans le cas d'une interface, voila comment je pensais l'implémenter:
    - Une "map" (concrètement un tableau de pointeurs de fonction), donc les clés sont des identifiants qui correspondent a un nom pleinement qualifié d'interface (codés par je ne sais quel algorithme miracle qui prend avantage du fait que seuls les caractères alpha-numériques sont autorisés dans les noms de paquetages), et dont les valeurs sont des pointeurs vers des structures qui contiennent un tableau de pointeurs sur les implémentation par la classe des fonctions de l'interface et ce dans le bon ordre de déclaration.
    En bref, une fois de plus, pour implémenter le polymorphisme j'utilise des structures avec des pointeurs sur fonction qui sont assignés aux bonnes implémentations a l'initialisation, et retournées suivant vers quoi on cast. Retourner le parent est "straight-forward", mais retourner une interface, pas, puisqu'une classe peut potentiellement implémenter un nombre infini d'interfaces et ce dans n'importe quel ordre.
    interface Callable { abstract func call; } // pas de différence de mot-clé entre super-classe/interface. bien? mal? c'est en réflexion. class Concrete from Callable { implement call { // blablablah. } } func doThing(Callable c) { c.call; } func main { // le fait de passer un Concrete au lieu d'un Callable // implique un cast implicite vers une interface doThing(new Concrete); }
    En résumé donc; il y aurait une pénalité pour caster vers une interface, mais une fois casté, l'appel de fonctions est aussi peu cher que l'appel de fonctions d'une classe/super-classe directement.
    
    Note: s'il y a une implémentation évidente, plus simple et plus performante à la fois, je suis tout à fait preneur. Sinon, je pense aller par cette voie.

Super un nouveau langage

Posté par mosfet () le 27/06/2009 à 12:25. (lien). Évalué à 1.

Cette depeche tombe a point car depuis un an maintenant je suis a la recherche de langage natif avec gestion automatique de la mémoire afin de proposer une surcouche haut niveau pour un de mes projets.
En effet je travaille sur un projet du nom de gynoid(clin d'oeil a android) qui consiste a wrapper en C les api des teléphones portables (wince, symbian, iPhone et peut etre un jour android si google l'autorise).
A l'heure actuelle l'acces a l'adressbook est en train d'etre finalisé et j'avais adopté pour ce framework une approche orientée objet afin de simplifier le wrapping objet plus tard.
Par exemple pour acceder aux contacts de l'adressbook on écrit :

// Desolé pour l'indentation c pas très lisible

ErrorCode err = 0;
int iCount = 0;

GDAddrBook* pAddrBook = NULL;
GDAbItem* pAbItem = NULL;

if (!GDAddrBook_Alloc(&pAddrBook) &&
!GDAddrBook_Init(pAddrBook, 0) )
{
GDAddrBook_GetCount(pAddrBook, &iCount);
for (int i = 0; i < iCount; i++)
{
if (GDAddrBook_GetItem(pAddrBook, i, &pAbItem) == 0)
{
GDCTSTR lpFirstName = (GDCTSTR) GDAbItem_GetProperty(pAbItem, eAbFirstName);

//GDConsole_Writeln(_T("FirstName %s\nLastName %s\n", ...);
_tprintf( _T("[%d] %s %s %s\n"), i, lpFirstName, lpLastName, lpMobTel);

GDObject_Release(pAbItem);
}
}
}

Chacun de mes "objets" GDxxxx derive d'une structure avec une variable pour les références comptées.
Problème c'est que les developpeurs aujourd'hui ne sont plus vraiment intéréssés par le C et ce d'autant plus qi'on developpe des interfaces graphiques, c'est pourquoi je cherchais un langage qui me permettrait d'offrir un langage plus haut niveau et rellement objet.
Je me suis tourné des le départ vers le langage D car il concu par des grands noms du C++(A. Alexandrrescu) et des experts en compilation (Walter Bright) mais le problème est que le compilateur n'est ps disponible sur plateforme arm et que le compilo gnu GDC n'est meme plus maintenu.
Par consqéquent ooc est une alternative sérieuse au D dans mon cas précis.
Je pense par contre que ce serait pas mal de lancer un projet pour implémenter un frontend au sein de gcc ou mieux au sein de llvm car cela permettrait par la suite de pouvoir générer u narbre syntaxique ou un truc du genre pour prendre en charge la complétion dans un IDE par exemple.
Bon d'abord je vais étudier un peu plus le langage et j'essaierais de donner un retour.

[^]Re: Super un nouveau langage

Posté par mosfet () le 27/06/2009 à 12:34. (lien). Évalué à 1.
Il y a une fonctionnalité du langage qui va assez rapidement m'intéresser, c'est l'équivalent des delegates en C# pour tout ce qui est événement graphique. Est ce que quelque chose dans le genre est prévu ?
- [^]Re: Super un nouveau langage
  
  Posté par mosfet () le 27/06/2009 à 16:12. (lien). Évalué à 2.
  Autre chose en ce qui concerne la gestion des chaines de caractères, sous Windows CE les chaines sont nativement en unicode UTF16 (const wchar_t*), sous symbian ca depend utf16 ou utf8, ...
  C'est pour ca que pour le moment j'utilise une macro qui me permet de compiler en fonction de la platforme soit en ansi soit en unicode.
  Ca serait pas mal de pouvoir faire la meme chose avec ooc
  Ca veut dire qu'au moment de la compilation on pourrait faire :
  
  func main
  {
  _tprintf( _T( "Hello world ))\n" );
  }
  avec _tprintf qui serait résolu en printf pour les systemes unix-like et en wprintf pour les systemes windows et symbian.
  Bon tout ca pour dire que j'aimerais que pour une fois un langage prenne en compte les spécificités des os mobiles.
  
  En ce qui concerne les delegates et les pointeurs de fonctions membres, on est limité par le C et ne pourrait on pas envisager a terme une version de ooc-++ mais ceci dit cela viendrait a perdre tout l'interet et dans ce cas la autant faire un nouveau langage dérive du C (tiens ca existe deja et ca s'appelle le D) qui ne se contente pas de wrapper un autre.
  Bref j'attends de voir comment va évoluer cette partie callbacks/delegates/pointeurs de fonctions.
  - [^]Re: Super un nouveau langage
    
    Posté par Amos Wenger (Jabber id, page perso, ) le 27/06/2009 à 17:12. (lien). Évalué à 3.
    Vive LinuxFR, on rencontre pas que des trolls!
    
    Pour répondre à tes questions une par une:
    * Oui, ooc est une alternative sérieuse au D dans ton cas, et je suis absolument motivé de corriger le générateur de code si le C produit ne compile pas pour un target ARM (j'ai l'habitude des plateformes *très comfortables*, e.g. Gentoo Linux sur un x86, donc j'ai des fois tendance à oublier que dans le monde réel il y a plus de contraintes.)
    * En effet, le D est un langage très bien conçu (à mon avis) et par des gens sérieux, mais les implémentations libres laggent méchamment derrière DMD, tout ça à cause de leur état d'esprit semi-propriétaire et c'est vraiment dommage.
    * Les delegates sont prévus, c'est de plus très rapide a implémenter, donc pas de souci de ce côté là.
    * Pour les chaines ASCII/UTF-16, etc. je te propose une solution que j'envisageais depuis longtemps: annoter les fonctions C, pour dire à quel type de String elles s'attendent, et permettre de surcharger le cast, pour passer par des fonctions de conversions. Qu'en penses-tu ?
    * Pour les pointeurs de fonction membres, je n'ai que survolé le sujet dans le language reference guide, mais mes plans sont assez précis. Peux-tu vérifier que les créateurs de LibJIT disent vrai quand ils prétendent supporter la plateforme ARM? (exemple essayer de compiler leurs exemples dessus). C'est par ici que ça se passe: [http://code.google.com/p/libjit-linear-scan-register-allocat(...)] Pourquoi un Just-In-Time assembler, me direz-vous? Pour faire du currying en ooc [http://en.wikipedia.org/wiki/Currying] c'est à dire "créer en temps réel une fonction avec qq arguments fixés" et je pense bien sur au premier argument, c'est a dire le pointeur vers la structure de l'objet duquel on appelle la fonction. Bien sur il faudrait benchmarker l'utilisation CPU/Mémoire additionelle que cela implique, mais ça serait *tellement* pratique que je pense que c'est intéressant tout de même. L'implémentation de la même méthode avec GNU lightning marchait a merveille =)
    
    Si tout ce que je raconte la haut semble te convenir, je te conseille de prendre le chemin du bug tracker d'ooc [http://bugs.launchpad.net/ooc-language] et de faire un rapport de bug par feature manquante (delegates, strings UTF-16, pointeurs de fonctions membres). Cela permettra de suivre l'évolution des discussions et de l'implémentation plus facilement.
    - [^]Re: Super un nouveau langage
      
      Posté par Nicolas Boulay () le 03/07/2009 à 00:21. (lien). Évalué à 2.
      Au fait, tu avais regardé le langage Lisaac avant de te lancer ?
      
      --
      "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
      - [^]Re: Super un nouveau langage
        
        Posté par Amos Wenger (Jabber id, page perso, ) le 03/07/2009 à 12:49. (lien). Évalué à 1.
        Le nom me disait vaguement quelque-chose, je viens d'aller voir sur Wikipédia, ce projet me semble intéressant aussi =) Dans ses différences avec ooc, Lissac = orienté prototype et héritage Smalltalk/Eiffel, ooc = orienté classe et héritage Java/C#, etc.
        
        [^]Re: Super un nouveau langage
        
        Posté par Nicolas Boulay () le 03/07/2009 à 17:40. (lien). Évalué à 2.
        Les buts ont l'air trés proche (Lisaac semble plus mature par contre)
        
        --
        "Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."

Sympa

Posté par Emeric () le 30/06/2009 à 10:34. (lien). Évalué à 1.

Sympa comme projet.

Il semble que que le programme généré ne soit pas entièrement portable suivant l'architecture cible.
Les Float sont des float donc dépendant de ce pourquoi on compile.

en tout cas bravo

[^]Re: Sympa

Posté par Amos Wenger (Jabber id, page perso, ) le 30/06/2009 à 16:34. (lien). Évalué à 1.
Merci pour les encouragements =)

J'aimerais avoir quelques détails sur en quoi les floats ne sont pas portables ? Si ce n'est que quelques architectures n'ont pas de registres flottants (mais là on peut pas vraiment incriminer le compilateur), vois-tu une autre manière évidente d'implémenter ça de manière portable ?

contribution

Posté par collinm (page perso, ) le 02/07/2009 à 02:15. (lien). Évalué à 1.

ça serait intéressant d'avoir une liste de fonctionnalité devant être implémenté, ligne directrice...

je code en java et C... ça fait un petit moment que j'ai pas touché au C... et je serais sûrement intéressé à participer.... s'il y aurait plus d'info sur ce qu'un volataire peut faire...

--
www.laboiteaprog.com

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Le language de programmation ooc sorti en version 0.2

Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

[^]Re: Hmmm

ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

[^]Re: ObjectiveC

Vala

[^]Re: Vala

[^]Re: Vala

[^]Re: Vala

[^]Re: Vala

[^]Re: Vala

[+] Et Vala ?

Version 0.2

[^]Re: Version 0.2

lan_GA_ge

[^]Re: lan_GA_ge

[^]Re: lan_GA_ge

hello world?

[^]Re: hello world?

[^]Re: hello world?

[^]Re: hello world?

[^]Re: hello world?

[^]Re: hello world?

Ooc !

[^]Re: Ooc !

[^]Re: Ooc !

[^]Re: Ooc !

Succès du langage

[^]Re: Succès du langage

[^]Re: Succès du langage

Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[+] [^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?

[^]Re: Rapidité du C ... et ramasse-miettes ?