Reprise du message précédent :
lui ca marche partouze xD et ya plus de code nah

Tsss moins y'a de code, et plus la solution est belle

 
Boost.Spirit n'est pourtant pas anachronique
 
 

A propos de D, ça a l air sympa, surtout au niveau des syntaxes simplifiées, forward déclarations, templates, fonction delegate et anonyme, + de gestions mémoire (tab/hash), plein de bonnes choses.
 
<<compilation très rapide>> heu.. même avec -O3?
 
Mais j aime pas trop le ramasse-miettes. J ai de mauvais souvenirs de lenteur avec ça.
 
Pas de inline: c est dommage pour les applis haute perf.
 
Les contrats ça a l air sympa, bien que je ne l utiliserai que pour du debug. nécessité assertion = mauvaise conception = *BSoD*
 
Les packages me rappelent les mauvais souvenir de l ADA: attention le programme va commencer dans 5 4 3 2 1 1/2..1/4..
 
Les modules eux, les mauvais souvenirs du Java: dur de ne pas commencer un petit projet en jettant des idées en vrac dans un bloc notes. ça à l air plus cool quand même.
 
Variables initialisées par défaut: ç est pire. t a toujours besoin d une initialisation ou alors ça plante quand tu fais la démo au client. (0 est un nombre aléatoire comme les autres )
 
<<la definition du langage, qui, contrairement a celle de C++, est claire et lisible>> ha bon, ya une def de C++?
 
<<Les pointeurs ... perte de performances>> plutot bizarre.
 
tableaux: .reverse / .sort : est ce util?
 
<<que l'héritage simple.>> dommage.
 
alias: introduire des ambiguïtés de vocabulaire?
 
L'opérateur & du C++ est supprimé: dommage, pointeur != reférence != copie, tous ont avantages & inconvénients.
 
 

O3 ne concerne que GDC, que je n'ai pas essayé. Je parle de DMD.
Maintenant que j'ai réinstallé un Linux sur ma machine, j'essaierai GDC.

Tu peux le désactiver si nécessaire.

Les jeux de Kenta Cho, comme Torus Trooper, peuvent donner une idée des perfs. On croirait qu'ils ont été écrits en C.

Non, ça peut être un facteur de sécurité supplémentaire quand on crée des librairies critiques utilisées par d'autres équipes, comme en aéronautique.
Bien souvent, dans ces domaines, on fait ce genre de tests d'intégrité et de pré/post-conditions de façon assez systématique dans le code de production, quitte à sacrifier un peu les perfs. Les contrats ont l'avantage d'offrir un cadre plus élégant qu'ajouter des if ou des macros un peu partout dans le code.

Je ne vois pas ce que tu veux dire.

Alors là, c'est tout bonnement faux. Il est vrai que le fait d'avoir des variables initialisées par défaut ne dispense pas le codeur de faire ce travail d'initialisation. La vraie différence est que les bugs sont facilement reproductibles et apparaissent de façon plus systématique en phase de test, parce que le comportement du programme n'est pas "aléatoire".
Les variables non initialisées sont une plaie parce qu'ils peuvent mener à des bugs très difficiles à débusquer, qui arrivent dans des conditions particulièrement tordues et rares, et ce des mois après la mise en production sur des systèmes fonctionnant 24h/24. Le débogage de ce genre de bugs peut parfois prendre des semaines.
 

Oui. C++ est normalisé, et la norme se trouve dans l'ARM.
 

A quoi fais-tu référence ? Je penses que tu fais un raccourci que je n'ai pas fait.

Bien sûr, surtout que ça ne coûte rien de l'ajouter.

Si tu considères que typedef le fait...

& est complètement inutile en D. Autant le supprimer.

D n'est pas une évolution du C++, et heureusement

muchacho> merci pour tes comments
 
C vrai, j avais pas voulu faire un post trop long, j ai un peu raccourci.
 
ramasse-miettes: ce serait plus normal qu on puisse l activer si necessaire. par exemple, la déclaration d un tableau statique en C se fait sans mot clé particulier, et prends 1 instruction machine. l opération new du C++ ne se fait pas en 1 seule instruction et est plus long à écrire. Si le gc était activé avec des mots clés style <<create/destroy>> ce serait sympa: la taille du source reflète la taille du code compilé. C est un détail, pourtant c est important quand tu débute dans un language pour prendre de bonne habitude.
 
Je ne discuterais pas des perfs, car je n ai pas essayé, je ne fait que des conclusion logiques.
 
En ce qui concerne la sécurité, le véritable élément de sécurité et le double-codage par deux équipes. Le reste, c est pour mettre les programmeurs dans le bain. (conclusion personnelle à la suite d un stage chez sextant avionique)
 
<<ne dispense pas le codeur de faire ce travail d'initialisation>> -> j en revient à <<de bonnes habitudes dès le départ>>.
 
Autre solution de déboggage: plutot que d attendre le bug, passer toutes les fonction pas à pas au debugger. Dans le cas contraire, prévoir une version NewTech du logiciel faite par une autre équipe, et merger les bouts de code qui marchent
 
Solution plus conciliante: ne pas intitialiser par défaut Sauf si le type possède une valeur par défaut dans sont typedef. (sympa, ça, non?)
 
Pour les pointeurs: dans la partie Types/ chapitre 2/ titre <<les pointeurs>> tu expliques que on utilise peu les pointeurs qui peuvent mener à une perte de perf par rapport aux autres utilisation possibles en D. A défaut d avoir des exemple concrets, je trouve ça bizarre. (pointeurs sont lents? ou reférences automatique sont plus rapides? ou références donc plus besoin de pointeurs?)
 
typedef/alias: en cours j ai appris à éviter le typedef-alias, les contre-exemples sont rares (Rech&Dev?).
 
En gros, pour résumer, D a quelques raccourcis de syntaxe qui peuvent faire prendre de mauvaises habitudes, car ne décrivant pas assez explicitement/logiquement ce qu en fait le processeur. C est ce qu on reproche en général aux langages que l on compare à C, ça vaut pour C++ (au moins dans ses premières versions).
 
PS: la norme C++ cétait une joke relatif au flou et aux évolutions. Un meilleur langage que D: <<man guru>>.
 
 
 
 

 
pas une franche rigolade, mais un petit sourire quand même ...

Comment ? par le biais de pragma, d'options de compilation, autres ?
(suivant la réponse), est-ce qu'un programme prévu pour utiliser le gc peut etre utilisé sans ? (et inversement)
 
 

... à l'époque. Il y a un document ISO depuis.
 
 

Pour donner de la sécurité vis à vis de la gestion de la mémoire, il n'y notament 2 solutions, les GC ou les pointeurs intelligents.
Les seconds ont des performances catastrophiques dans un contexte multithread. Pour plus de détail, voir les papiers sur le site de H. Boehm.
 

Les compilateurs d'aujourd'hui n'ont plus guère besoin de inline.
 

CQFD.
 

D n'est visiblement pas dans une optique : donnons de l'expressivité au langage, et faisons le maximum d'évolution en ajoutant des bibliothèques ... Alors la réponse est peut-etre tristement oui.
 

drole de façon de le voir ... Je trouve que c'est une bonne idée, et C++ la reprendra probablement.
 
 

+1,

Et on merge le résutat ?  
 

Pas tant que ça. Personnellement, je les évite dans un cas : j'ai besoin de faire une déclaration anticipée -- et je ne peux pas le faire sur un typedef.
 

J'aime bien les histoires, et je déteste ne pas en comprendre le sel, tu peux étayer stp ?

 
J ai écrit plus haut ironiquement: ha bon une definition de C++?
 
Au début du C++, les programmeurs osaient à pène appeler le C++ du <<C avec des classes>>. La norme était plutot floue, et d un compilateur à l autre il y avait des différences notables, aussi bien dans le code généré que le code source. Depuis de nombreuses évolutions ont permis de standardiser ce langage, bien qu il soit toujours en évolution. Tous les langages en passent par là, et les programmeurs qui en font les frais préfèrent ironiser.
 

 
Tu tapes <<man guru>> dans to shell linux, si tu trouves pas essaye avec google. Il y en a d autres dans le même genre (man boss par ex.)
 
fab> Pour le ramasse miette, tu peut le désativer en surchargeant le destructeur. Perso, je préfèrerait l inverse pour satisfaire: ajouter du code <=> ajouter fonctionnalité
 
double-codage par deux équipes: Et on merge le résutat ? oui, exemple: win98+winNT=winXP . Pour les applis sécurité quand un des deux programmes plante l autre prends la relève.
 

le ramasse miette est une fonctionnalité de base de D..
ca me ferrait chelou de devoir activer les classes en c++ =)

Tu les actives en utilisant le mot-clé <<class>> au lieu de <<struct>>.

dans le même principe ^^ tu es contre le GC dans java ?

Disons que faut avoir un peu de bouteille pour ironiser. Du temps de L'ARM, j'étais dans les limbes, aujourd'hui, je me contente de m'extasier du résultat ( ... à venir ... ).
 

ça ne me dérange pas. C'est le seul moyen ?

 
struct sert aussi à déclaré une classe
 
sinon c++ est multi-paradigmatique et on n'est pas obligé d'utiliser le support oo du langage

fab> je vois que tu as un peu de bouteille
 
skelter> je la sentais venir cette remarque, struct au lieu de class, c est quand même pas propre.
 
benO> je dois répondre là? ya déjà des thèses et des thèses qui ont été écrites sur le sujet du GC.
D après mon expérience personnelle, j évite d utiliser le GC, donc j évite Java. Si quelq un me prouve que GC a de meilleures perfs, je veux bien changer d avis. Idem si quelq un me démontre mathématiquement que les programmes avec alloc. dynamique ont une probabilité de bug supérieure à GC.
 

ben il suffit de les lires les thèses que tu cites

ben il suffit de les lires les thèses que tu cites

 
Que ? par rapport a quoi ? Un GC aura tjs de moins bonne perf (vitesse) face un langage sans GC pour la bete raison qu'il fait du boulot que l'autre ne fait pas
 
par contre quand t'as une appli qui tourne en continu t'as interet a bien assurer tes desalloc, paske un leaks ca devient vite problématique, sans GC

Non
 

Aux spécificateurs d'accès près, c'est identique. Pour en revenir au sujet qui provoque cette digression, une façon d'"activer" les classes C++, c'est de les rendre non POD, d'une manière ou d'une autre.
 

H. Boehm et les papiers qui trainent sur son site devrait pouvoir te convaincre du contraire -- dans certaines situations.

nargy : ton opinion sur le GC est louable.
 
Mais ta volonté à modifier un lang pour le faire coller à ta vision
du monde est incompréhensible ^^
 
D et Java, ont été concu avec une GC par défaut par leurs auteurs respectifs, et vouloir les voir sans cet attrribut est aussi inapproprié
que de vouloir voir le c++ avec une GC par défaut xD
( quoique ^^ sur ce point, c'est discuté :> )
 
Nous programmeurs, avons un ensemble de languages à notre disposition
et devons nous demerder avec ^^
 
Même si j'étais convaincu que les GC étaient inutiles, j'irais pas proposer
qu'on l'enlève de Java..
 
Je respecte ton avis , je comprend ton point de vue sur les GC,  
mais je ne suis pas d'accord avec le fait d'appliquer notre point de vue n'importe ou xD
 
Si on t'écoutait, Il n'y aurait de GC nulpart et on ne laisserait
pas la chance à cette techno/concept d'exprimer tout son potentiel.
 
que penses tu de http://www.digitalmars.com/d/garbage.html ?

rien que l'allocation, un first-fit ou un best-fit contre un eden space, c'est vite vu.

surveuille un peu ton langage stp

 
Non, si on me lisais seulement, on prendrait en considération que j ai proposé de créer des mots-clés spécifiques pour allocation GC: create et destroy.
 
Pour moi, il ne s agit pas de mettre en conflit les méthodes de gestion mémoire, simplement d avoir le choix, et si possible un choix cohérent avec:
plus de code source <=> (équivaut) plus de fonctionnalité <=> (équivaut) plus de code machine
(Note: je n ai pas dit qu il faut recoder la gestion GC à chaque programme, ni l allocation dynamique, d accord pour la simplification syntaxique)
 
GC est un progès indéniable en matière de simplifcation de code source. Mais c est aussi une opération coûteuse en temps machine. Aussi, une solution de compromis est nécessaire. L important, c est d avoir le choix pour pouvoir utiliser la bonne méthode au bon moment.
 

 
(certaines situations = aucune allocation croisée) => eden space
 

J'vois pas où est l'intérêt, si tu veux un GC tu utilises un langage garbage-collecté, si t'en veux pas tu utilises un langage non garbage collecté, terminé

Ca n'a rien de cohérent, d'habitude c'est même l'inverse, moins on a de code source (langages fonctionnels/très haut niveau) plus le langage est expressif et a de fonctionalités, et ces constantes inverses sont grandement indépendantes du montant de code machine généré derrière

par contre, il manque des trucs dans les debuggers par rapport au GCs, pour suivre les chaines de pointeurs entre les roots et les objets dont on pense qu'il devraient être détruits.

Avoir besoin d'un GC pour certains objets au sein d'une application, pouvoir basculer le tout en utilisant un GC sauf pour certains objets, etc, ce sont des besoins qui existent. le WG21 prends en compte ces besoins.  
 

et tu ferais quoi des objets sans GC ??
 
pour quel use-case veux-tu virer le GC ?

Il les manipulerait probablement manuellement (au risque de tout faire pêter, mais c'est un risque de la manipulation manuelle dans tous les cas) à coup de malloc ou new

 
Je les détruit à la main avec delete ( suivant les pragma/autres ), possiblement de la meme manière qu'un objet garbage collecté -- pour lequel le delete est ignoré. Voir tout les proposals sur les GC ici : http://www.open-std.org/jtc1/sc22/ [...] pers/2005/ (et antérieur à 2005)
C'est pas facile à suivre parce que certaines propositions en évincent d'autres, mais on voit les idées.
 

- je suis dans un contexte non multithread, et pour des raisons de perfs, je préfère utiliser un pointeur intelligent. (éventuellement Juste pour les objets qui représente le goulet d'étranglement)
- j'ai des contraintes fortes d'occupation mémoire, je dois pouvoir garantir à quel moment seront libérer mes objets, et je n'ai pas besoin d'avoir une allocation rapide.
- ... (probablement énormément de situations que je ne connais pas)

1) mais un GC est au moins aussi rapide qu'un pointeur intelligent, ne serais-ce que parce que l'affectation ne nécessite pas d'accès au référé.
 
2) tu peux utiliser un GC exact si tu veux troquer de la perf contre de la mémoire.
 
comment gères-tu un GC avec du non-GC ? l'intégrité de ta mémoire n'est plus garantie.

D'apres les tests de h. boehm pour son GC, un pointeur intelligent type shared_ptr, sans controle de référence circulaire, serait "globalement" plus efficace dans un contexte monothread que son GC.
 

Je ne connais pas. Mais je doute que ça rende la libération d'un objet prévisible, si ? Et accessoirement, il faut pouvoir en disposer d'un. En existe t'il un pour C++? est-ce que boehm est configurable pour ça ?
 

Je ne connais pas les détails de l'implémentation, mais apparemment ça fonctionne bien.

1) son GC est la technomogie la plus mauvaise qui existe (c'est pas de sa faute, il a pas le choix), les GCs conservatifs. Un GC normal est bien plus efficace (en fait c'est toujours plus effice un Gc en environnement sûr : comme c'est un assemblage de techniques, quand ton contradicteur commence à te chauffer, tu changes les réglages vers la technique qui donne le mieux pour un problème donné et en voiture Gertrude).
 
2) exact, ça veut dire "exactement au moment où c'est plus nécessaire", exactement lors de la destruction de le dernière référence depuis une racine. Donc c'est plus où moins prévisible, en moyenne, ça arrive avant un destructeur explicite. Et si ça produit pas avant l'endroit où tu pensais que ça arriverait, ben c'est que t'as encore une référence sur l'objet et que t'aurais fait une connerie avec un destructeur.
 
3) bah t'a intérêt à t'y intéresser, parce que ça sert à rien d'avoir un GC avec un trou dans le graphe des objets, il te sauvera pas la mise.

Je constate quand même que malgré le fait que le troll la discussion lancée sur les GC par nargy concerne initialement les performances avec/sans GC, personne n'a encore fait remarquer que quasiment tous les langages fonctionnels sont implémentés avec un GC, et que pourtant certains sont plus rapides que le C/C++ (notablement certaines implémentations de Common Lisp, légèrement plus lentes en moyenne mais plus rapides sur certains champs spécifiques comme la manip' de listes, et surtout Standard ML avec le compilo MLTon qui a la caractéristique de switcher dynamiquement entre 3 stratégies de CG et 4 de Copying Collector au runtime, en fonction du mode le plus efficace sur les données courantes)
 
sinon, il me semble bien que Modula-3 gérait à la fois le GC et la gestion manuelle, mais il utilisait deux heaps séparées (une pour le GC et une pour l'alloc' manuelle) et je ne sais pas du tout comment étaient gérée les références entre les deux heaps (genre un objet alloué manuellement qui référence un objet garbage collecté et qu'on oublié de dégager )

Effectivement, je m'étais un peu avancé. Il est vrai que le templates de C++ sont censés être Turing-complets et qu'ils doivent donc en principe permettre tout type de programme. M'enfin je n'ose pas imaginer la gueule du code derrière Spirit. D'ailleurs il y a du monde pour le codage...
 

Je t'en prie.  
 

Sauf que d'un coté tu parles d'allocation statique et de l'autre d'alloc dynamique. En C, malloc prend bcp plus d'une instruction machine, et je ne parle pas de calloc, "équivalent" des déclarations de tableaux en D.
 

Le double-codage coûte plus de 2x plus cher et n'existe pratiquement que dans l'avionique à ma connaissance car bien peu d'industries peuvent se permettre de doubler les coûts de dev pour s'assurer un petit delta supplémentaire de sécurité. Je ne suis même pas sûr que ce soit pratiqué dans le contrôle nucléaire, ni même dans le contrôle aérien. Et il me semble que Sextant a à son passif l'explosion d'Ariane 5, donc c'est un peu normal qu'ils aient renforcé la sécurité. Bref, c'est une pratique très exceptionnelle. Par contre, la programmation par contrats, sans être une pratique extrêmement répandue, est parfois utiisée dans l'industrie. L'idée étant que quand tu livres ton bout de code, il soit à peu près blindé contre toutes les conneries que peuvent faire les utilisateurs.
 

Les bonnes habitudes, c'est une chose, mais l'erreur est humaine, et aucun programmeur ne peut se targuer de ne jamais en faire.  
 

C'est strictement impossible la plupart du temps. Ne serait-ce qu'essayer de passer dans plus de 80% des branchements, c'est déjà bien souvent prohibitif pour un programme modérément complexe (et je parle d'expérience). Quand tu as atteint ce taux de couverture, tu as déjà mieux testé ton code que 95% du code de production pondu quotidiennement dans le monde entier. Là encore, il n'y a guère qu'en avionique qu'on exige 100% de couverture des branchements possibles.
 
A mon avis, l'initialisation de données doit compter pour 1% du temps machine pour une appli standrd avec un taux d'utilisation CPU non négligeable. Les quelques boucles et tableaux à optimiser peuvent se passer d'initialisation, mais pour la grande majorité du code, ça ne va strictement rien changer aux perfs.
 

Relis-ma phrase, tu l'as comprise à l'envers. J'ai écrit "D supporte les pointeurs de la même manière que C++, mais le langage allant dans le sens de la simplification, il offre des facilités qui font qu'en pratique, on s'en sert relativement peu sans risque de perte de performances."
Je dis donc que malgré le fait qu'on se serve peu des pointeurs, il n'y a pas de pertes de perfs. Ce qui implique que les pointeurs sont un moyen de programmation performant.
 

Ce sont des mots-clés qui servent à la compatibilité avec du code dont on n'a pas forcément la maîtrise. Ce n'est pas là pour être élégant, c'est juste parfois nécessaire.
 

Comme tous les langages, c'est un compromis. A chacun de faire son choix.
Je n'entrerai pas dans le débat pour/contre les GC, on sait que c'est stérile. Je me bornerai simplement à dire que l'auteur de D, Walter Brght, connait parfaitement les implications de son choix sur le design de son langage, et qu'il n'est pas vraiment un petit nouveau dans le monde de la compilation, étant aussi l'auteur de plusieurs compilateurs C++, dont l'un des meilleurs parmis les premiers compilos C++, à savoir Zortech C++, puis de celui de Symantec (qui a longtemps été le seul pour Mac).

eupe ni vu ni connu avec une bonne page sur les templates: http://www.digitalmars.com/d/templates-revisited.html

Le langage va tout doucement vers sa version 1.0.
Walter Bright le fait évoluer à toute vitesse, c'est impressionnant.
Il intègre désormais, entre autres:
- des tuples sous forme de templates
- l'évaluation paresseuse avec le mot-clé lazy
- la RAII et les scopeguards avec le mot-clé scope. Les scopeguards sont une manière alternative de traiter les erreurs inventée par A. Alexandrescu.
 
A titre utile, lorsque le GC se révèle lent:

ca fait longtemps que j'ai pas regardé du côté de D.
 
existe-t-il des IDEs performants actuellement?