Jonathan MERCIER a écrit 42 commentaires

oui je suis d'accord l'article est bref et ne développe c'était avant tout de faire une première aproche en essayant de satisfaire ceux qui ont jamais vu du D et ceux quelque fois.

Le type size_t est un alias vers uint ou ulong selon que l'on se trouve en 32 ou 64 bits. Je l'ai volontairement utilisé abusivement pour marqué que ce type existe. La taille d'un tableau est de size_t.max ainsi lorsque l'on manipule des tableaux il vaut mieux utilisé size_t .

pour ce qui est de args :

import std.stdio;

void main( string[] args ){
    writeln(args);
}

$ ldc2 cmd.d
$ ./cmd 
["./cmd"]
$ ./cmd je test une longue phrase
["./cmd", "je", "test", "une", "longue", "phrase"]

les attributs @xxxx permettent de mettre en place des optimisations pour le compilateur qui ne sont pas détectable ou pas facilement. Certains d'entre eux permettent de garantir la fiabilité de la fonction rendant le programme finaux plus sûre, la sécurité des applications est un gros problème en programmation.

Ce n'est justement pas un langage avec des idées de 30 - 40 ans. Voici un court script pour effectuer les opérations décrites ci-dessus. A noter que les opérations utilisant map et reduce sont parallélisées.

import std.string;
import std.stdio;
import std.algorithm;
import std.array;
import std.typecons;
import std.math;

void main( string[] args ){
    int[] tab   = [-1, 0, 1, 2, 3];
    tab         = array(map!("a + 1")(tab));
    writeln( tab );
    size_t moyenne = reduce!("a + b")(0, tab) / tab.length;
    writefln( "La moyenne est de %d", moyenne);

    auto r = reduce!("a + b", "a + b * b")(tuple(0, 0), tab);
    writefln( "somme: %d | somme des carées: %d | moyenne: %d |  écart type: %f",
                                                                                    r[0],
                                                                                    r[1],
                                                                                    r[0] / tab.length,
                                                                                    sqrt(cast(float)(r[1] / tab.length - moyenne * moyenne))
                                                                                    );
    string toto = "Mon prénom est " ~ "Toto";
    writeln(toto);
    string toto2 = "Mon prénom est %s".format( "Toto" );
    writeln(toto2);
}

[0, 1, 2, 3, 4]
La moyenne est de 2
somme: 10 | somme des carées: 30 | moyenne: 2 |  écart type: 1.414214
Mon prénom est Toto
Mon prénom est Toto

le D peut s'interfacer facilement avec le C , pour le C++ j'ai jamais essayé il pose quelque fois des soucis.
Binding en D que j'ai utilisé:

• gtk
• openGL
• SDL
• freeglut
• GLFW 2 et 3
• X11
• sqlite
• fastcgi

il y en a d'autre j'ai vu sur github un projet se nommant deimos répertoriant quelque binding

Non justement, de base

• char => caractère unicode 8
• string => tableau de caractère unicode 8 + fonction manipulation de chaine + immutable
• wchar => utf 16
• dchar => utf32

si le développeur veut utiliser autre chose que de l'unicode dans ce cas il le précise par le biais de la locale ou réencode juste la chaine de caractère voulu

Je ne pense pas qu'il soit dans une démarche constructive étant donné que sous C++ le code aurait le même comportement. Mais plutot une volonté de nuire.

Le soucis sous pour l'encodage des caractères c'est qu'il n'est pas possible de connaitre l'encodage de ta console aussi simplement. Tu peux créer des moyens plus ou moins automatique pour connaitre l'encodage de la console et ainsi obtenir des caractères lisibles sur ta console. le module std.encoding est utilisé en ce sens.

Pas la peine de mettre de la méchanceté ou toute autre démarche ayant pour simple but de nuire. De la a dire que c'est pas normale que le programme plante car on dépasse volontairement le tableau et que c'est pas normal. c'est un peu fort de café surtout que le C++ segfaulterait tout au temps. Idem pour l'encodage il faut préciser la locale utiliser par la console en C++.

Je ne pense pas qu'il soit intéressant ou constructif de s'énerver. Discutons débattons paisiblement bien que le sujet des langage tends a attirer les trolls …

import std.stdio;
import std.array;
void main ( string[] args){
    if( args.length == 2 )
        writefln("Bonjour: %s", args[1] );
    else if ( args.length > 2 )
        writefln("Bonjour: %s", args[1..$].join(", ") );
    else
        writefln("Bonjour" );
}

$ ./t
Bonjour
$ ./t jean paul eric
Bonjour: jean, paul, eric

pour le range error c'est normal je n'est mis aucune vérification ce n'était pas l'objectif.
Pour ce qui est des caractère unicode le D le gère nativement dans le cas de windows c'est la console windows qui ne gère pas les caractères unicode. Comme tu l'a dit en 2012 un OS qui gère pas sur la console l'unicode …

Bonjour, vous utiliser une très veille version du langage. Je vous conseille d'installer le dépôt debian mentionner dans l'article.

pour des raisons de vouloir être succins je n'ai pas mis toutes les fonctionnalités de plus la fonction main peut retourner 0, 1 ou autre si vous le souhaiter.
L'utilisation de scope(exit) par exemple permet de positionner des instructions avant de quitter une fonction. Par exemple fermer un fichier, relacher un mutex …

Oui Opera a ce système depuis longtemps

Exactement ce que je voulais dire non a SDL!

Personnellement j'ai découvert GLFW et c'est un framework vraiment intéressant et la version 3 qui arrive promet !!

Pour ma part, je serais bien intéressé pour développer un jeu en D + GLFW3 + OpenGL3
voilou, sait ton jamais si des personnes veulent essayer.

Pourquoi le D, en 2 mots: simple d'utilisation et exécution rapide
Inconvénient: récent donc peu de bibliothèque ( Mais justement ça permet de d'approfondir pas mal de chose )

Afin de complété la panoplie des version fedora. Je suis actuellemnt sous fedora 16.
J'utilise XFCE en cas de soucis et en principal Gnome-shell. les problèmes rencontrés sont un big avec Gconf2 et un bug avec nautilus. Pour autant cela reste une version alpha. J'utilise en lieu et place de nautilus, thunar. et voilou.
Gnome-shell est vraiment récent, les utilisateurs sont pas habitué, et il y a quelque bug.
Pour autant je suis ravis de pouvoir contribuer a l'aventure linux en rapportant ces petits bug.
Maintenant si tu veux de la stabilité au sens on connait les problème centos ou debian. En effet si on était exempté de bug les mises à jour serait inutile....

La D2 est stable
GDC est à jour et marche avec la D2
Phobos2 est stable
Tango2 n'a pas fini son portage D2

Le langage D me séduit bien plus que le Go, syntaxe, maintenant, performance ... que du plaisir

Note: GDC sera intégré en standard a partir de gcc 4.7

Je me retrouve en accord avec la plupart des réponses ici à propos du Go. Je pense que Go a de l'avenir non par le langage mais du fait qu'une grosse entreprise est derrière. L'idée de départ est intéressante la gestion faciliter des thread une bonne idée mais globalement pas convaincu.

Je me suis mis au D, ayant l'habitude de java, c++ et python (et eiffel pour les connaisseurs). J'ai trouvé un langage qui a fusionne les avantages de ces trois langages.
Toutefois tout n'est pas rose le langage est relativement jeune du coup on croule pas sous les bibliothèque et on découvre de temps en temps des bugs. Ceci est toutefois rattrapé par une communauté proche a l'écoute et dont les fixes arrivent vite une fois détecté.
Pour moi un langage a suivre le D, j'ai éliminé le scala a cause de la JVM mais j'en convient qu'il est intéressant

L'article bien que globalement rédigé me pose un soucis j'ai de nombreuse personne qui me sont revenu et on cru que c'était ubuntu qui développer wayland ....
Faut le dire c'est un projet red hat il bosse dessus depuis au moins 2008. Alors s'il vous plaît utiliser moins de détour. Oui vous avez dit qui était l'auteur principale tout en évitant soigneusement de dire qui développer le projet ...
Sincèrement ç& m'a énerver quand plusieurs personne m'on dit (suite a la lecture de cet article)
" ubuntu développe wayland un nouveau truc super bien bien qui remplace X11"
GRRRR

Je me suis fait plaisir :)
Il n'est pas possible de réécrire l'existant en D, le python remplit très bien ses missions. L'ajout du langage D et pour se tourner vers l'avenir et mettre à disposition des développeurs des outils pour travailler dans ce langage.
J'ai travailler upstream dans la philosophie de fedora par conséquent le travail sera profitable à tout le monde.
Pour une personnes ayant fait un des langages suivant: C++, Java, Python, Ruby
J'estime à un mois le temps d'être opérationnelle afin d'apprendre l'API. Par la suite la productivité est proche de ce qui est fait avec Python.
Bonne continuation

Euh c'est pas la faute a fedora.
Fedora travaille upstream contrairemnt a d'autre et ne veut pas modifier le logiciel mais le livré tel quel. S'il y a de ssoucis on va coté upstream. Personellemnt je préfère cet approche au moins ça profite à tout le monde.
donc pour le coup des icones faites un rapport de buh chez GNOME