signifie, pour un être humain normal, [2,3,4]. Alors oui, c'est certain, un cerveau est >assez flexible pour comprendre que ça n'est pas le cas et d'apprendre comment faire une boucle à la place
Pas besoin de faire une boucle : int[] array = [1, 2, 3]; array[] = array[] + 1; // [2, 3, 4]
Il n'y a quasiment rien qui n'est plus valable(et ce n'est pas au niveau des specs du langage, mais de Phobos), néanmoins le livre contient un certain nombre d'erreurs que tu peux consulter ici.
Depuis le livre grosso modo, je dirai qu'il y a eu l'ajout des UFCSs(je ne suis pas sur mais je pense qu'il les a utilisé dans le livre(avant qu'ils implémentent le truc)), et la nouvelle syntaxe lambda C#-like(on peut utiliser l'ancienne encore) :
voidmain(){autofoo=delegatestring(stringbar){returnbar;};// comme dans le livreautofoo2=(stringbar)=>bar;// une autre possibilité maintenantwriteln(foo("bar"),foo2("bar2"));// output : barbar2}
Voilà en gros.
Sinon depuis le livre ils ont implémenté @property, @safe, alias this est utilisable maintenant(avant y'avait des gros bugs, maintenant y'en a moins), je sais pas ce qu'il en est de inout j'ai encore jamais eu le plaisir de l'utiliser.
Non absolument pas, tu te doutes bien que si les programmeurs D sont contents d'immutable c'est parce qu'ils aiment pas trop le const de C++.
Le const de C++ n'est pas transitive, tandis que le const et l'immutable de D le sont.
Le const de C++ n'offre quasiment aucune garantie au niveau de la thread-safety.
Le const de C++ se rapproche plus du const de D(avec notamment la notion de transitivité comme grosse différence), certainement pas d'immutable. :)
En règle générale, std.stdio n'est pas du tout apprécié par la communauté.
Apparemment un nouveau module std.io va bientôt(entendre par là quelques mois ou versions) être écrit, à vocation d'être moins buggé(et aussi pour rajouter de nouvelles fonctions mais bon), pour rendre remplacer std.stdio sur le long terme(j'imagine que dans un premier temps il sera marqué deprecated).
Quand une data est marquée immutable, elle ne pourra jamais changer, elle sera de même valeur durant toute l’exécution du programme, comme dans un langage fonctionnel.
Au niveau de la concurrence de D2, immutable permet d'être thread-safe.
Donc vu que le compilo sait que la data est immutable, il peut optimiser en fonction.
Tandis que const donne juste la garantie qu'une référence vers la data marquée const ne changera pas celle ci(la référence), par contre une autre référence vers le même objet est en droit de le modifier.(alors qu'avec immutable non)
En gros immutable est à utiliser quand la data doit rester la même du début à la fin de l'éxécution et const est plus pour garantir que la data ne sera pas modifier avec l'identificateur marqué const.(en paramètre d'une fonction par ex.)
voidmain(){int[]a=[1,2,3];immutable(int)[]b=a;//Error: cannot implicitly convert expression (a) of type int[] to immutable(int)[]b[0]=0;// ne compilera oh grand Dieu jamais}
Les bindings les plus utilisables sont, pour moi, GtkD(qui est un wrapper OO, même si vu le manque de doc c'est galère à utiliser) et Derelict2(une collection de bindings dynamiques pour le dev de JV), il y a Derelict3 qui commence à grossir petit à petit mais c'est déjà utilisable. ;)
La dépêche est bien rédigé, elle présente bien la facilité du langage.
Seulement, je trouve que la fonction avec les delegate :
pure size_t f( in size_t delegate(size_t) pure dg1, in size_t delegate(size_t) pure dg2) {
return dg1( x ) + dg2( x );
}
est trop verbeuse, surtout qu'en soit cela n'apporte rien en terme d'optimisations ou autres.
J'aimerai bien que tu expliques si @safe pure nothrow @trusted @system, apporte quelque chose en terme d'optimisations ou si c'est pour faire joli ? (j'ai jamais compris à quoi ça servait en pratique :d)
Sinon tu aurais pu parler des templates constraints, des mixin et de la CTFE aussi, c'est quand même les grosses features de D.
immutable permet une plus grande sécurité que const, c'est une des directions majeurs de D2 par rapport à D1.
Sinon pour size_t, non c'est pas vraiment courant dans les sources que tu trouveras, j'avoue que ça fait pas très idiomatique.
C'est juste la façon de coder de l'auteur. :)
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 6.
Pas besoin de faire une boucle :
int[] array = [1, 2, 3];
array[] = array[] + 1; // [2, 3, 4]
C'est joli hein ? :D
[^] # Re: «the D programming language»
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 3.
Il n'y a quasiment rien qui n'est plus valable(et ce n'est pas au niveau des specs du langage, mais de Phobos), néanmoins le livre contient un certain nombre d'erreurs que tu peux consulter ici.
Depuis le livre grosso modo, je dirai qu'il y a eu l'ajout des UFCSs(je ne suis pas sur mais je pense qu'il les a utilisé dans le livre(avant qu'ils implémentent le truc)), et la nouvelle syntaxe lambda C#-like(on peut utiliser l'ancienne encore) :
Voilà en gros.
Sinon depuis le livre ils ont implémenté @property, @safe, alias this est utilisable maintenant(avant y'avait des gros bugs, maintenant y'en a moins), je sais pas ce qu'il en est de inout j'ai encore jamais eu le plaisir de l'utiliser.
# Autres articles
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 2.
Pour ceux qui aimerait en savoir plus à propos de D, il y a d'autres articles abordant d'autres features intéressante : Cool features of the D language, Three unlikely successful features of D(Andrei Alexandrescu, video talk LangNEXT 2012), The D programming language(Walter Bright, video talk LangNEXT 2012), What does C++ do better than D.
[^] # Re: Le langage D est-il choisi lorsqu'on ne sait pas avec quoi coder ?
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 4.
Non absolument pas, tu te doutes bien que si les programmeurs D sont contents d'
immutable
c'est parce qu'ils aiment pas trop le const de C++.Le
const
de C++ n'est pas transitive, tandis que le const et l'immutable de D le sont.Le
const
de C++ n'offre quasiment aucune garantie au niveau de la thread-safety.Le const de C++ se rapproche plus du const de D(avec notamment la notion de transitivité comme grosse différence), certainement pas d'immutable. :)
[^] # Re: Je cherche à comprendre
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 1.
En règle générale,
std.stdio
n'est pas du tout apprécié par la communauté.Apparemment un nouveau module
std.io
va bientôt(entendre par là quelques mois ou versions) être écrit, à vocation d'être moins buggé(et aussi pour rajouter de nouvelles fonctions mais bon), pour rendre remplacerstd.stdio
sur le long terme(j'imagine que dans un premier temps il sera marquédeprecated
).[^] # Re: Le langage D est-il choisi lorsqu'on ne sait pas avec quoi coder ?
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 4.
Quand une data est marquée
immutable
, elle ne pourra jamais changer, elle sera de même valeur durant toute l’exécution du programme, comme dans un langage fonctionnel.Au niveau de la concurrence de D2,
immutable
permet d'être thread-safe.Donc vu que le compilo sait que la data est
immutable
, il peut optimiser en fonction.Tandis que
const
donne juste la garantie qu'une référence vers la data marquéeconst
ne changera pas celle ci(la référence), par contre une autre référence vers le même objet est en droit de le modifier.(alors qu'avecimmutable
non)En gros
immutable
est à utiliser quand la data doit rester la même du début à la fin de l'éxécution etconst
est plus pour garantir que la data ne sera pas modifier avec l'identificateur marquéconst
.(en paramètre d'une fonction par ex.)Ceci t'expliquera mieux que moi ;)
[^] # Re: attributes
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 1.
Certes, mais en terme d'optimisations ?
[^] # Re: Est-ce que le langage D possède des bindings stables ?
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 3.
Les bindings les plus utilisables sont, pour moi, GtkD(qui est un wrapper OO, même si vu le manque de doc c'est galère à utiliser) et Derelict2(une collection de bindings dynamiques pour le dev de JV), il y a Derelict3 qui commence à grossir petit à petit mais c'est déjà utilisable. ;)
# attributes
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 2.
La dépêche est bien rédigé, elle présente bien la facilité du langage.
Seulement, je trouve que la fonction avec les delegate :
pure size_t f( in size_t delegate(size_t) pure dg1, in size_t delegate(size_t) pure dg2) {
return dg1( x ) + dg2( x );
}
est trop verbeuse, surtout qu'en soit cela n'apporte rien en terme d'optimisations ou autres.
J'aimerai bien que tu expliques si @safe pure nothrow @trusted @system, apporte quelque chose en terme d'optimisations ou si c'est pour faire joli ? (j'ai jamais compris à quoi ça servait en pratique :d)
Sinon tu aurais pu parler des templates constraints, des mixin et de la CTFE aussi, c'est quand même les grosses features de D.
Cool en tout cas,
[^] # Re: Le langage D est-il choisi lorsqu'on ne sait pas avec quoi coder ?
Posté par Eyyub . En réponse à la dépêche Le langage D. Évalué à 2.
immutable permet une plus grande sécurité que const, c'est une des directions majeurs de D2 par rapport à D1.
Sinon pour size_t, non c'est pas vraiment courant dans les sources que tu trouveras, j'avoue que ça fait pas très idiomatique.
C'est juste la façon de coder de l'auteur. :)