Discussion :

[Invité]

Anales de Mathématiques Pures et Appliquées de Galois

Un livre résolument chiant.


Plus sérieusement, Emmanuel, je crois que je comprends mieux ton point de vue d'architecte maintenant. En tout cas merci d'avoir expliqué.

[Mac LAK]

Désolé pour le retard.

Je suis bien d'accord qu'un acces en lecture ne pose-- de manière très théorique du moins, à condition de faire l'impasse sur les accès concurrent -- à peu près jamais de problème.

Tu peux oublier la concurrence dans les paramètres : c'est la même chose avec les méthodes (quoi qu'elles soient).

Par contre, un acces en écriture se doit d'être aussi encadré que possible et d'être permis de manière aussi restreinte que possible

Ai-je dit le contraire ? Justement, c'est pour ça que j'apprécie les propriétés : possibilité d'avoir l'équivalent d'un attribut, mais en lecture seule (= sous-entendu "consultation libre", mais pas touche en écriture).

tu permet à tout le code d'avoir un acces en écriture sur des objets au sujet desquels un tel acces devrait être particulièrement restreint.

Bien sûr que non. J'utilise fréquemment un système de verrou par TLS par exemple, qui restreint l'accès à certaines méthodes à certains threads seulement : c'est très utile pour éviter d'avoir à dériver une classe particulière suivant l'accès autorisé ou pas, et se retrouver au final à devoir détruire/reconstruire des classes "pour rien" quand les threads changent de rôle.
(Pour simplifier, c'est un problème de multiplexage de threads "drivers" qui doivent passer en mode stub de façon dynamique en fonction d'un état global. Le problème étant d'avoir quelque chose d'extrêmement performant tout en étant robuste)

Je suis, encore une fois, désolé d'insister sur ce point, mais c'est loin d'amener une situation idéale

C'est bien mieux qu'un accesseur, qui est quelque chose de quasiment impossible à empêcher / contrôler (ce n'est qu'une méthode, après tout !!!), tandis qu'une propriété a au moins le mérite d'être clairement identifiable, et potentiellement restreinte.

pire encore, tu encourage le développeur à fournir un acces en écriture à un attribut qui, non seulement, ne devrait déjà pas être accessible en lecture "depuis l'extérieur", mais au sujet duquel il est encore plus incohérent d'envisager d'en permettre un acces en écriture.

T'inquiètes pas : ce genre de bestiau fait en général un accesseur et un mutateur en même temps que son attribut. C'est triste, mais c'est pourtant le cas... T'as pas idée du nombre de gens qui considèrent comme "obligatoire" d'avoir deux accesseurs (publics, bien sûr) pour CHAQUE attribut interne... Et qui te regardent comme un alien quand tu leur demande pourquoi ils ne virent pas leur fonction en mettant l'attribut public.
Sans vouloir lancer un troll, ils sont en général issus de Java...

J'ai même déjà vu cette horreur (refaite de mémoire) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#define MAKE_ATTRIBUTE(aName,aType) \
private: aType aName ; \
public: aType get##aName () { return this->aName ; } \
public: void set##aName ( aType aValue ) { this->aName = aValue ; }

Avec les attributs de la classe définis via cette macro.

Oui, je t'accorde cinq minutes pour pleurer.

Bien sur, tu me dira qu'il faut laisser les "bons" programmeurs faire le boulot, mais je te rappelle encore une fois que tous ne sont pas aussi bons qu'ils ne peuvent le laisser croire...

Yep, mais bon : t'as des garde-fous à ce niveau aussi... Relecture des specs / conceptions, documentation automatique et relecture de ladite doc (plus rapide et pratique que de relire le code), et bien sûr l'utilisation des classes en question.

Ca facilite grandement, au contraire, vu, qu'à l'extrême limite, il suffit d'une ligne de code pour... exposer aussi bien le mutateur que l'accesseur...
Et c'est presque plus un risque qu'un avantage...

La même chose avec les attributs (mettre "public:" devant), les accesseurs triviaux (cf. horreur ci-dessus), etc.

Tu le sais aussi bien que moi, l'homme est par nature un imbécile distrait.

Oui, c'est pour ça que je garde précieusement Sœur Matraque près de moi, pour limiter la distraction...

Le programmeur n'étant qu'un homme, il est, lui aussi, un imbécile distrait (et je me mets volontiers en tête de liste )

C'est pour ça que l'on a plein d'outils pour limiter la casse, à condition de les utiliser et de lire ce qu'ils nous disent.

Au final, si tu donnes la possibilité à quelqu'un de modifier un attribut alors qu'il ne le devrais pas, tu dois t'attendre à rencontrer "un imbécile" pour essayer de le faire.

Certes. Mais c'est la même chose partout : j'ai déjà vu des goyots mettre en commentaire la ligne "private:" d'une classe pour accéder à ses attributs privés sans en hériter ou devoir écrire une méthode d'accès... Et un "//", c'est plus rapide à insérer que n'importe quelle propriété.

Bref, avec les propriétés, tu as beaucoup trop tendance à centraliser des comportements qui feraient beaucoup mieux... de rester clairement séparés.

C'est là où je ne suis pas d'accord... Une entité = un concept. Maîtrise l'entité, tu maîtrises le concept et réciproquement.

En simplicité et en capacité de faire des conneries, parfois même sans s'en rendre compte, parce qu'un caractère "malencontreux" peut te faire passer en "ecriture"...

Ah, tu parles d'un problème spécifique à la grammaire (pourrie) du C et C++, là...
Ce problème est impossible dans beaucoup de langages, comme (au hasard) Delphi, et de façon générale tous les langages non-issus du C.
Mais bon : un compilateur bien réglé t'envoie un beau warning là-dessus, encore faut-il lire ces warnings et ne pas les masquer.

Tu as, sans doute, un attribut qui garde en mémoire le nombre d'éléments que ta collection comporte, et tu as:

• une (série de) fonction(s) dont le comportement est clairement déterminé susceptible(s) de modifier cet attribut
• un seule et unique fonction te permettant de récupérer le nombre d'éléments contenu

J'ai donc UNE propriété donc la lecture renvoie cette information (possibilité unique), et dont l'écriture effectue un comportement clairement déterminé en fonction de la valeur écrite... Je ne vois pas la différence, sauf que j'ai tout centralisé en un seul point au lieu d'avoir des \see longs comme le bras dans une demi-douzaine de fonctions.

A vrai dire, je fais partie de ceux qui regrettent profondément la présence de [] dans les std::map et qui regrettent encore plus profondément le fait que la sémantique qui est donné à cet opérateur permette aussi bien de rechercher un élément que d'en insérer un...

Franchement, sans cet opérateur, ça fait longtemps que je n'utiliserais plus DU TOUT les maps de la STL... Je ne suis pas le seul, je pense, et les itérateurs font partie des choses franchement rebutantes... Le pire : certains se targuent d'un code imbitable qui serait, selon eux, du code "pro"... Ce qui m'a toujours fait marrer quand on passe en phase d'optimisation, d'ailleurs, car leur code "pro" y survit rarement.

Partique, peut être, mais, encore une fois, à quel prix

Au prix d'avoir un langage plus accessible et moins "élitiste" qu'il ne l'est actuellement... Ce qui n'est pas un mal : certains points du C++ sont franchement des usines à gaz.
Pour ma part, j'ai toujours trouvé les prototypes des templates STL parfaitement infects et illisibles... Peut-être trouves-tu ça "expressif", mais moi, j'y vois seulement un magma infâme digne de l'IOCCC.
Heureusement, il y a des choses pratiques dedans comme les ... opérateurs [] !

Encore une fois, en centralisant plusieurs comportements fondamentalement différents en un seul terme, tu augmente le risque de voir apparaitre des contre sens ou des erreurs dues, essentiellement... à la mauvaise évaluation du sens à donner à ce terme dans une situation donnée

C'est là que tu vois des comportements "différents" là où je n'en vois qu'un seul : gérer la taille du container.

L'adaptation aux circonstances que tu permet au travers de propriétés (RW, je l'accorde), c'est d'avoir des comportements fondamentalement différents, et c'est là que repose le problème

Tant que tu restes sur le principe "action hyper-élémentaire", effectivement, tu auras un souci avec ça. Il faut passer un cran au dessus pour bien comprendre les propriétés...

Je dis cela sans méchanceté aucune, mais peut-être est-ce trop difficile de faire ce "saut" pour quelqu'un qui est trop ancré dans le C++ (ou le C). Pour ma part, j'ai appris la POO avec Pascal, puis Delphi, puis Java (très brièvement), et en dernier C++ : cela m'a permis de voir certains aspects vraiment intéressants de chaque langage, et surtout, les "manques" de chacun.

Au niveau de la documentation à fournir, tu ne gagne pas grand chose à utiliser les propriétés, ne serait-ce que du seul fait que, si elles présentent deux comportement, tu devra quand meme documenter les deux comportements mis en oeuvre, et tu devra, en plus, indiquer dans quel cas tel ou tel comportement sera mis en oeuvre.

Bien entendu. Mais je n'ai alors qu'UN SEUL point de documentation, et non pas N points avec l'obligation de créer des références manuellement entre eux... En effet, tu n'as souvent rien qui permette de lier automatiquement (par le code) ces entités : ça ne te choque pas ? Moi, si...

et devoir me rappeler de... tous les cas d'utilisation

Ce qui revient au même que de te rappeler de toutes les fonctions...

Sans oublier, en plus que le simple fait d'écrire = au lieu de == risque de provoquer des catastrophes.

C'est un manque grave de la grammaire, donc du langage, et non pas des propriétés... Et un réglage correct du compilateur permet de le détecter immédiatement. Argument non-recevable !

Cela ne rend, effectivement, pas l'interface plus complexe, mais, encore une fois,à quel prix

• Cela rend plus complexe le fait de déterminer exactement le comportement que l'on met en oeuvre en fonction du "contexte"
• Cela risque d'entrainer des catastrophes si, d'aventure, on utilise le "mauvais contexte"
• Cela ne rend pas forcément la lecture et la compréhension plus facile

Je suis désolé, mais c'est un prix que je ne suis pas près à payer si je peux l'éviter...

Le contexte est simplement le fait d'avoir une L ou une R-value... Faut pas abuser non plus, la propriété doit avoir un nom parlant comme tout identifiant (ex : "Size" et non pas "IO0Ol1"), et si tu tombes sur un développeur qui n'est pas capable de distinguer sa gauche de sa droite sur une affectation, conseilles-lui de se reconvertir dans l'élevage d'escargots.

Ne t'en fais pas pour ca... je suis connu pour la longueur de mes posts

J'ai ouï-dire qu'il en était de même pour moi...

[JolyLoic]

Léger HS, si ça continue, je splitterai la discussion...

C++/CLI est là pour ça.

Je ne suis pas vraiment d'accord. Il est là pour faire l'interface entre les deux mondes, ce qui est à des kilomètres de fournir une interface graphique utilisable en vrai C++.
Et puis en plus, WPF ne supporte pas le C++/CLI. Ce dont je rêve c'est plus d'une biblitohèque en vrai C++ qui s'inspire des concepts de wpf, car eux sont intéressants (et demandent des propriétés pour être utilisable de manière à peu près fluide).

Par contre, la barrière est plus lourde que tu ne le crois : tu ne peux attacher qu'un seul débugger à l'exécutable, soit en mode managé, soit en mode natif. Quand tu arrives au wrapping managé/natif (importation DLL ou appel vers le managé), ton debugger ne permet plus de tracer dans le source, hélas : il voit la fonction de "l'autre monde" comme quelque chose d'atomique, et ton debugger ne passe pas automatiquement du mode managé au mode natif et réciproquement.
Très pénible quand on fait du debug de wrappers... OK, c'est un cas particulier, mais il se trouve que je suis passé en plein dedans pour avoir développé, justement, des interfaces C#/C++ générales (et générées).

Je travaille depuis plusieurs années dans ce contexte, et je peux dire que ça ne pose pas de problème. Il suffit dans les options du projet C# de cocher Debug/Enable unmanaged code debuging, ou dans les options de projet C++ de sélectionner Debugging/Debugger type/Mixed.

[Invité]

Oui, il faudrait une discussion "les propriétés encouragent elles les mauvais comportements ?" ou "Pour ou contre les accesseurs, la bataille finale".

[Mac LAK]

Léger HS, si ça continue, je splitterai la discussion...

Yep, ça pourrait être intéressant.

Je ne suis pas vraiment d'accord. Il est là pour faire l'interface entre les deux mondes, ce qui est à des kilomètres de fournir une interface graphique utilisable en vrai C++.

Certes, ce n'est pas du "vrai" C++, on est d'accord... Et ça t'oblige à écrire une IHM avec une partie réellement de présentation, et une partie fonctionnelle sous forme de DLL (d'un autre côté, on devrait toujours faire comme ça...).

Et puis en plus, WPF ne supporte pas le C++/CLI. Ce dont je rêve c'est plus d'une biblitohèque en vrai C++ qui s'inspire des concepts de wpf, car eux sont intéressants (et demandent des propriétés pour être utilisable de manière à peu près fluide).

Je vois mieux ce que tu veux dire...
Pas gagné, regarde Borland et BCB : pour supporter la VCL, ils ont ajouté une extension au C++ pour, justement, permettre le concept de propriété... Souci : syntaxe C++ oblige, c'est (je trouve) plus "lourd" que l'équivalent Delphi, et ton code n'est plus du C++ compatible avec tous les compilateurs.

Je travaille depuis plusieurs années dans ce contexte, et je peux dire que ça ne pose pas de problème. Il suffit dans les options du projet C# de cocher Debug/Enable unmanaged code debuging, ou dans les options de projet C++ de sélectionner Debugging/Debugger type/Mixed.

Tiens, marrant, ça : le paramètre "Automatique" est donc trompeur... Il se résume à un choix définitif entre du debug managé et natif, alors qu'il aurait tendance à faire croire que le switch est automatique. De plus, sa position dans la liste laisse sous-entendre que c'est le réglage le plus "puissant", et il n'en est rien.

Bon, je n'avais pas cherché trop loin non plus étant donné que j'avais de toutes façons deux systèmes de log de part et d'autre (prévus dans le fonctionnel), que j'avais donc utilisé pour ce debug, mais ça me permettra de virer le code de trace ou d'éviter d'en ajouter sur une nouvelle interface. Merci.

[screetch]

...

on a globalement deux visions qui difèrent
ta vision, c'est que le code doit être facile a ecrire
ma vision, c'est que le code doit être facile a (re)lire

dans ta vision, avoir 14 points d'entrée différent est pénalisant lors de l'écriture du code; besoin de vérifier la documentation, etc etc
dans ma vision, avoir un même mot faisant plusieurs choses complique la relecture.

toujours dans ma vision (j'espere qu'il y a assez de disclaimer) la relecture est bien plus importante que l'écriture, d'où l'interet (pour moi) d'ecrire des mots (et pas des symboles) qui ont un sens, et qui expliquent l'action devant être effectuée.
L'indication de l'action, sa complexité et son comportement sont indiqués par de nombreux points, parfois c'est implicite et parfois c'est explicite.
par exemple, je m'attends a ce que la fonction insert execute une insertion et rien d'autre. sa complexité n'est pas ecrit dans son nom mais plutot dans le type utilisé; si un map a une complexité en O(n2) je vais être un peu décontenancé.
enfin, toujours dans ma vision, un accès raccourci a des fonctionnalités (comme une propriété, ou un operateur[]) obscurcissent le code source a la relecture.
Car, dans mon esprit, la connaissance du fonctionnement d'un opérateur ou d'une propriété ou d'un raccourci ne devrait pas être un prérequis pour la compréhension du code qui l'utilise. Si je travaille dans une base de code de plusieurs milliers de fichiers, des millions de ligne de code, il m'est impossible de connaître par avance le fonctionnement de chaque fonction/opérateur/propriété. En revanche, si chaque fonction est suffisemment explicite (dns son nom) pour dire ce qu'elle fait (et donc ce qu'elle ne fait pas) je n'ai plus besoin d'aller lire sa documentation ou de l'apprendre par coeur.

Ce dernier point, j'espère, tu n'auras pas l'audace de le contester. En revanche je comprend ton point de vue (a l'opposé du mien) qui revient a pouvoir ecrire du code et effectuer des actions avec du code de plus haut niveau.
De mon point de vue (disclaimer...) le code est plus souvent relu qu'ecrit, et de plus il contient moins d'erreurs lorsqu'il est clair.

[screetch]

oui j'ai bien compris. mais utiliser du code d'une bibliothèque c'est bien ecrire du code non ? (en en utilisant un autre)
j'ai donc bien compris que ton code de bibliothèque doit rendre l'ecriture (des autres) plus simples.
moi j'estime que le code doit être facile a relire et que pour cela, bien souvent, le plus simple est d'utiliser des interfaces elles-mêmes sobres et claires, quitte a rendre leur utilisation plus contraignante (du point de vue de l'ecriture)
tu publies une interface pour les autres, les autres doivent relire leur code, ton interface fait donc partie de leur code. Lorsqu'ils reliront leur code, ils reliront ton interface, d'ou l'importance de ne pas aller verifier pour chaque fonction que tu as publié ce qu'elle fait "pour de vrai".

[deadalnix]

Je crois que vous vous égarez.

En C++, on a tous un tas d'outils qui peuvent avoir de très mauvais usages, comme par exemple, en vrac :
1/ Les pointeurs.
2/ La gestion manuelle de la mémoire.
3/ La surcharge d'opérateurs.
4/ Le renvoie de référence d'objets locaux.

Et bien d'autres.

Et pourtant, je ne crois pas que quelqu'un ici veuille éliminer ces fonctionnalités. Je ne vois pas pourquoi la question devrait se poser pour les fonctionnalité ajoutées par D.

Penser qu'un fonctionnalité n'est pas utile n'est pas une raison suffisant pour vouloir la supprimer du langage. Si vous pensez cela, alors C++ n'est définitivement pas pour vous, et vous devriez plutôt aller voir du coté des catégories C# ou Java du forum

[koala01]

C'est bien mieux qu'un accesseur, qui est quelque chose de quasiment impossible à empêcher / contrôler (ce n'est qu'une méthode, après tout !!!), tandis qu'une propriété a au moins le mérite d'être clairement identifiable, et potentiellement restreinte.

Tu me dira bien comment tu restreint d'avantage une propriété (en dehors du fait quelle permet un acces en lecture, en écriture ou les deux) qu'un accessseur, qui, dans l'idéal, renvoie une valeur constante et est... une fonction constante...

Dés le moment où tu expose une propriété, cela revient exactement au même que d'exposer l'accesseur, le mutateur ou le couple des deux sur... l'attribut concerné...

T'inquiètes pas : ce genre de bestiau fait en général un accesseur et un mutateur en même temps que son attribut. C'est triste, mais c'est pourtant le cas... T'as pas idée du nombre de gens qui considèrent comme "obligatoire" d'avoir deux accesseurs (publics, bien sûr) pour CHAQUE attribut interne... Et qui te regardent comme un alien quand tu leur demande pourquoi ils ne virent pas leur fonction en mettant l'attribut public.
Sans vouloir lancer un troll, ils sont en général issus de Java...

Justement, si tu facilite les choses pour la création des deux, tu as tendance à les conforter dans l'idée que... c'est ce qu'il faut faire...

Et donc, tu perd une possibilité de leur "apprendre" que ni l'un ni l'autre n'est d'office obligatoire.

D'autant plus que, à bien y réfléchir, en gardant les deux clairement séparés, tu peux leur faire la remarque deux fois (on ne sait jamais, au cas où la première fois n'aurait pas été comprise )

Yep, mais bon : t'as des garde-fous à ce niveau aussi... Relecture des specs / conceptions, documentation automatique et relecture de ladite doc (plus rapide et pratique que de relire le code), et bien sûr l'utilisation des classes en question.

Tant que le code est "interne"...

Tu as très rarement la certitude que ta bibliothèque sera correctement utilisée un fois qu'elle sera "diffusée"

Le malheur veut qu'elle peut être utilisée aussi bien par des gens compétents et responsables que... par de véritables gorets...

La même chose avec les attributs (mettre "public:" devant), les accesseurs triviaux (cf. horreur ci-dessus), etc.

Ce que j'essaie de te faire comprendre, c'est qu'il n'est pas forcément nécessaire de donner à l'utilisateur (du code ou du langage) une corde supplémentaire pour se pendre...

C'est pour ça que l'on a plein d'outils pour limiter la casse, à condition de les utiliser et de lire ce qu'ils nous disent.

Bien sur, tu as les avertissement du compilateur...

Encore faut il...

• que la personne qui les lis ne se dise pas "bah, ce n'est qu'un avertissement"
• que la personne qui décide de les prendre en compte soit en mesure de les comprendre, et, mieux encore, d'y apporter une solution

Vous pouvez croire, à me lire, que j'ai une bien piètre opinion de mes "collègues", et je vous rassure: je sais qu'il y a de très bons programmeurs, à tous points de vue... Le malheur est, selon moi, que le pire côtoie régulièrement le meilleur dans la profession

Au prix d'avoir un langage plus accessible et moins "élitiste" qu'il ne l'est actuellement... Ce qui n'est pas un mal : certains points du C++ sont franchement des usines à gaz.

Je reconnais le coté usine à gaz de certains points du C++...

Mais, crois tu réellement que c'est donnant un langage que d'aucuns pourraient considérer comme "simple" que nous améliorerons la qualité générale des applications, surtout de celles créées par le quidam moyen

Je suis désolé, mais, pour ma part, j'ai l'impression que, plus on tente de faire passer la programmation pour une discipline facile ou aisée, plus on a de chances de voir y venir des gens incapables...

J'ai, surement, l'air élitiste dans mes propos, mais, lorsque je voit le nombre de gens qui savent utiliser un edi ou un RAD, mais qui sont incapables de concevoir *correctement* une application ou une logique à mettre en oeuvre, je ne peux m'empêcher de penser qu'ils seraient surement plus efficace à planter des patates

C'est là que tu vois des comportements "différents" là où je n'en vois qu'un seul : gérer la taille du container.

Si ce n'est que tu n'utilise pas la granularité suffisante dans ce terme:

Les comportements sont:

• d'un coté, permettre à l'utilisateur de connaitre la taille
• de l'autre, permettre à l'utilisateur de modifier la taille

Tant que tu restes sur le principe "action hyper-élémentaire", effectivement, tu auras un souci avec ça. Il faut passer un cran au dessus pour bien comprendre les propriétés...

Je dis cela sans méchanceté aucune, mais peut-être est-ce trop difficile de faire ce "saut" pour quelqu'un qui est trop ancré dans le C++ (ou le C). Pour ma part, j'ai appris la POO avec Pascal, puis Delphi, puis Java (très brièvement), et en dernier C++ : cela m'a permis de voir certains aspects vraiment intéressants de chaque langage, et surtout, les "manques" de chacun.

Et je connais suffisemment les langages que tu cites pour savoir que ces aspects qui représentent, selon toi, un manque, sont en fait les outils tous trouvés pour assister à un "nivellement vers le bas", permettant aux programmeur de ne pas se poser certaines questions pourtant primordiales pour la qualité de l'application

Bien entendu. Mais je n'ai alors qu'UN SEUL point de documentation, et non pas N points avec l'obligation de créer des références manuellement entre eux... En effet, tu n'as souvent rien qui permette de lier automatiquement (par le code) ces entités : ça ne te choque pas ? Moi, si...

Pourquoi faudrait il lier automatiquement plusieurs fonctions dans la documentation

Ce qui revient au même que de te rappeler de toutes les fonctions...

Je suis désolé, mais non...

Si tu as un certain nombre de fonctions dont les noms sont explicites, tu sais, en permanence l'action qu'aura une fonction donnée...

En multipliant les comportements "en fonction des circonstances ou du contexte" qu'aura un terme donné, tu multiplie le risque de... choisir le mauvais contexte...

Le contexte est simplement le fait d'avoir une L ou une R-value... Faut pas abuser non plus, la propriété doit avoir un nom parlant comme tout identifiant (ex : "Size" et non pas "IO0Ol1"), et si tu tombes sur un développeur qui n'est pas capable de distinguer sa gauche de sa droite sur une affectation, conseilles-lui de se reconvertir dans l'élevage d'escargots.

Si ce n'est que, encore une fois, l'instruction qui utilise la propriété risque d'être "noyée" parmi un tas d'autre lignes de code...

Si, à un moment, tu lis un resize(), dans un code, alors que toutes les lignes précédentes te font penser que tu manipule une collection en lecture seule, tu va, immanquablement, te poser des question.

Si, à l'occasion d'une lecture "un peu trop rapide", tu rencontre une propriété size dans les mêmes conditions, tu n'aura *pas forcément* le réflèxe de vérifier s'il se trouve à gauche ou à droite "d'un unique caractère" (noyé parmi d'autre, pour t'assurer que c'est bel et bien un acces "en lecture" et non un acces "en écriture" qui est effectué

J'ai ouï-dire qu'il en était de même pour moi... [/QUOTE]

Ce qui n'est pas le cas, par exemple, de resize qui (je le rappelle) sous-entends que l'on RE-alloue la taille... De quelle manière ? Absolue ? Relative ? Que se passe-t'il au premier appel ? Quel est l'état initial ?

Basiquement, on s'en fout... A condition de mettre en oeuvre les *bons* principes (RAII en tête):

De deux choses l'une:

Soit, tu viens de créer ta collection (comprenons nous sur le terme: tu l'a créé dans la fonction dans laquelle tu souhaite appeler resize ) , et tu y a, éventuellement ajouté un certains nombre d'éléments... Tu *sais* donc, en fonction des instructions qui séparent la construction de la collection de l'invocation de resize(); ce que la collection contient

Soit, la dite collection est créée "par ailleurs" et passée en argument (ou membre d'une classe plus complexe), et, quoi qu'il en soit, si tu as décidé qu'il ne devait y avoir que N éléments, il n'y en aura ni plus, ni moins...

C'est pour cette raison qu'il est largement préférable de faire en sorte que la taille s'adapte automatiquement sur certains comportements utilisables par ailleurs tels que l'ajout, la suppression ou la "vidange", quitte à permettre par ailleurs de définir une taille arbitraire (opération qui échoit à... resize() )...

[Invité]

Tu me dira bien comment tu restreint d'avantage une propriété (en dehors du fait quelle permet un acces en lecture, en écriture ou les deux) qu'un accesseur, qui, dans l'idéal, renvoie une valeur constante et est... une fonction constante...

La propriété est une fonction (où plutôt une ou deux fonctions) qui a pour particularité d'être appelée avec une syntaxe d'affectation.
Elle ne correspond pas forcément à un attribut, et peut tout à fait être const ou renvoyer un objet const...

Je ne voudrais pas que tu crois que le D encourage par design une certaine facilité et une mauvaise conception.

Les propriétés, et tu as raison, encouragent à créer plus d'accesseurs puisque c'est plus facile. Tu n'aimes pas, ok. Généralement ce qu'on dit à quelqu'un qui n'aime pas une feature de C++ c'est "tu n'es pas obligé de l'utiliser".

Les gens qui trouvaient que les propriétés avaient trop d'inconvénients ont d'ailleurs obtenu que l'annotation @property soit obligatoire. Ce n'est donc plus implicite comme avant.

Mais il ne faut pas jeter le bébé avec l'eau du bain.

Il faut savoir que Walter Bright,à cause de son passé chez Boeing, a une sensibilité particulière pour la sureté d'un langage et les vies que ca peut sauver.
Il a pour objectif de faire de D un langage beaucoup plus safe, voire facile a vérifier automatiquement avec de l'analyse statique.

Aussi chaque décision est prise à la lueur de ce que tu viens de dire : le programmeur moyen est... moyen, et ne mérite pas qu'on lui accorde une pleine confiance - sans toutefois l'émasculer. Il a donc le droit de faire n'importe quoi, mais pas dans un subset "safe" du langage qu'il active là où il veut.

La safety correspond de fait à un certain nombre de features:

- les tests unitaires intégré, contrats : c'est plus facile, donc ca encourage à en faire
- les attributs @safe, @trusted et @disable dans D2
- la const-correctness de D2 beaucoup plus systématique, qu'on a pas tendance à éviter (ce qui pose d'ailleurs des problèmes de verbosité...)
- l'alias this encourage la composition sur l'héritage...
- le compilateur repère des cas d'erreurs comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (condition);
{
   ...
}

entre autres joyeusetés.

[_skip]

En work in progress

Le D-IDE
http://d-ide.sourceforge.net/

Ca pourrait être un point de départ pour développer une communauté autour de ce langage. Un langage, même excellent, sans véritable outil de développement, est une cause perdue.

[Invité]

Oui enfin il y en a pas mal en "work in progress". Le vrai problème est plutôt de pouvoir utiliser un débugger sous Windows.

Perso je suis sous Codeblocks, mais il faut debugger autrement

[_skip]

Genre ton debugger c'est printf?

[Invité]

[deadalnix]

Avec code::block + gdb sous linusque, tout marche impeccable chez moi. Le debug se fait bien.

[Niark13]

Aucun problème pour débugguer sous linux.
Pour développer, j'utilise JEdit + gdb + Scons pour le build.

[Klaim]

Hop je remonte ce thread parceque The D Programming Language: Amazon.fr: Andrei Alexandrescu: Livres en anglais@@AMEPARAM@@http://ecx.images-amazon.com/images/I/41-Go5vQ-WL.@@AMEPARAM@@41-Go5vQ-WL sur D va arriver chez moi aujourd'hui ou demain et qu'il semblerait qu'il devienne plus ou moins le bouquin référence pour l'ensemble de la communauté (que je ne suis pas mais le language m'interesse).

Avec un peu de chance (pour ce language), il y aura une vrai spécification dans quelques temps.

[Goten]

Ouai j'ai vu qu'il était sorti et en effet c'est LE bouquin qui va faire référence. (du pur Alexandrescu dans le texte).
Ma to-read-list est trop longue pour l'instant mais dans un futur pas très proche je pense que je me le prendrais car y'a définitivement des trucs très intéressant dans ce langage.

[Klaim]

Je n'ai pas fini de lire le livre (j'ai un livre sur l'histoire du jeu vidéo du point de vue sociétées et personnes à finir) mais j'ai remarqué que le site officiel a une nouvelle page de description plus claire et plus rapide a lire que le livre : http://www.digitalmars.com/d/2.0/overview.html

Les concepts repris et non-repris du C++ sont clairement listés donc c'est facile de mieux comprendre a quoi s'en tenir.

Hmm je pense que je tenterai un prototype de petit jeu dans ce language l'année prochaine, histoire de voir...


edit> Tiens il y a même une page de comparaison avec C++0x : http://www.digitalmars.com/d/2.0/cpp0x.html


Personellement, l'absence de séparation déclaration/définition m'ennuie. J'ai pratiqué du Java, de l'ActionScript, du C# etc. et ça me choque toujours d'avoir a parcourir du code effectif juste pour repérer des noms de fonctions. Partir du principe qu'on va toujours utiliser un éditeur (supposé en Java et C#) est particulièrement naïf je trouve.

[Florian Goo]

Merci pour le lien Klaim, je vais aller me lire ça.

Ça commence à être utilisé dans l'industrie, le D ?