Discussion :

[Emmanuel Deloget]

Parce que tu as pris l'habitude de te taper ça. Moi, j'ai pris l'habitude d'avoir plus simple et, surtout, d'avoir quelque chose de nettement plus proche du raisonnement humain tout en restant à un niveau d'efficacité proche de l'optimal. Via des propriétés, la taille (pour continuer cet exemple) est alors une entité à part entière, UNIQUE, que tu manipules en fonction de tes besoins et non pas quelque chose de "diffus" accédé au travers de 3 ou 4 fonctions plus ou moins cohérentes.

Mouais. Peut-être.

Je sens quand même un poil de mauvaise foi, ou peut être une indication de dissonance cognitive (va savoir ; je pencherais presque pour le second, tant il me parait plus honnête que le premier).

En quoi un accès à conséquences multiple à une unique entité est plus explicite qu'un accès à conséquence unique à de multiples entités ? En quoi est-ce différent du raisonnement humain de dire que resize() change la taille telle que donnée par size() ?

A mon avis, mais je peux me tromper, tu confonds simplicité et simplisme.

(..snip..)
Ce qui alourdit très nettement l'écriture et l'utilisation dudit container, sans parler des risques de pertes de performances... Inconvénients que n'ont pas les propriétés. La "tripaille" interne reste tout aussi "diffuse" avec les propriétés (plusieurs méthodes privées nécessaires pour réaliser les actions atomiques), donc pas de changements majeurs pour le développeur, mais l'interface publique (celle de l'utilisateur) est naturellement centralisée.

On se fait un petit plaisir, ne parlons pas de performance. Il n'y a de toute façon pas de différence majeure en termes de performance entre l'appel explicite d'un mutateur et l'appel implicite de celui ci via l'utilisation d'une propriété. C'est dans les deux cas le compilateur qui fait le sale boulot d'optimisation, quitte à aller jusqu'à l'inlining complet de l'appel.

Je ne suis pas vraiment d'accord avec toi en ce qui concerne les qualités des propriétés au niveau de l'interface publique d'une classe. La "centralisation" (je pense que je vois ce que tu veux dire) n'est pas un but en soi. Parmi les buts qu'on se doit d'essayer d'atteindre lors de la définition d'une interface, citons la cohérence, la lisibilité, et l'expressivité. D'autres buts sont bien évidemment à atteindre. La centralisation telle que tu la présente a des effets plus ou moins néfaste sur certains de ces buts.

• lisibilité : une propriété représente quelque chose d'intrinsèque à l'objet. Hors le principe même de la programmation orientée objet, c'est de cacher les données intrinsèque et de déterminer les traitements (qui vont être décrit sous forme de méthodes) que peut subir cet objet - dans le cadre de la résolution d'un problème défini. Il est beaucoup plus aisé pour nous de réfléchir en termes d'actions qu'en terme de définition (sinon les maths seraient facile pour tout le monde ; la dernière fois que j'ai vérifié, ça n'était pas le cas). Un programme est une suite de traitement - ce n'est pas une collection de donnée. Mélanger définition et traitement dans une même section de code rends le code plus difficile à déchiffrer.
• expressivité : une fonction fait une chose unique (dans l'idéal). Une propriété peut être accédée de manière différente (par exemple en lecture et en écriture). Elle fait donc plus de chose, mais est décrite avec un nom unique. L'utilisation d'un nom unique réduit d'autant l'expressivité de ce nom - par rapport à l'utilisation de plusieurs noms différents, chacun lié à une action particulière.

On peut argumenter sur le fait que les propriétés ne servent à rien. Dans l'ideal, il devrait être possible d'écrire un programme sans accesseurs et sans mutateurs, et donc sans propriétés. Un conteneur n'a pas besoin d'avoir une propriété Size si je peux utiliser les algorithmes du conteneur (par exemple une méthode foreach(), ...).

Ne te méprends pas : cet argument est volontairement idéaliste (et prends comme point de départ une application vertueuse de la loi de Demeter) - il n'a pas pour but de passer le test de la pratique (en tout cas, pas de ta pratique ; je pense que je peux y arriver, en tout cas pour certains problèmes simples, tout en respectant MON style de programmation). En fait, dans le projet que je réalise actuellement pour le compte d'un client, les seuls accesseurs présents sont utilisé dans les tests unitaires (pour vérifier que (par exemple) les séquences d'initialisation se passent correctement). Un seul est utilisé dans le code réel de l'application - dans le contexte de la récupération de valeurs lue dans un fichier de configuration au format XML. Le projet n'est pas vraiment de taille mirobolante, mais c'est quand même un projet pro, avec les contraintes liées à ce type de projet.

[Invité]

[*] expressivité : une fonction fait une chose unique (dans l'idéal). Une propriété peut être accédée de manière différente (par exemple en lecture et en écriture). Elle fait donc plus de chose, mais est décrite avec un nom unique. L'utilisation d'un nom unique réduit d'autant l'expressivité de ce nom - par rapport à l'utilisation de plusieurs noms différents, chacun lié à une action particulière.

Je regrette mais non, pas du tout. Les propriétés permettent justement d'être expressif là où on ne peut pas avec des appels de fonctions.
Si le même nom existe pour la lecture et l'écriture ET que la séquence d'action est cohérente, alors on est plus expressif (transmettre l'idée).

Pour un exemple imaginaire où vous mourrez d'envie d'agrandir de 4 la place disponible dans un tableau:

En D:

Code :

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

1
2
3
4
 
A[] tableau;
...
tableau.size = tableau.size + 4;

et même depuis quelques temps :

Code :

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

1
2
3
4
 
A[] tableau;
...
tableau.size += 4;

En C++:

Code :

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

1
2
3
4
 
std::vector<A> tableau;
...
tableau.resize (tableau.size() + 4);

Quelle version est plus lisible et plus expressive ? Vous trouvez peut-être le C++ plus lisible car vous êtes familier avec, mais c'est tout.

Qui plus est en C++ je vais évidemment lire la doc vu que resize appelle un constructeur par défaut sur chaque nouvel élément alloué, et que ca a des implications...

Si je n'avais rien à faire de l'expressivité, j'écrirais du COBOL.

[screetch]

c'est plus une question de choix, une opinion, qu'un fait. Tu peux debattre de cela 20 ans, je ne changerai pas d'idée et je vois mal mac lak changer d'idée non plus.

[Invité]

Je ne faisais que répondre à des trucs comme:

resize() fait exactement ce que son nom indique.
size non, et a besoin d'une documentation.

Effectivement on changera pas d'avis.

[Alp]

Bon après l'expressivité c'est rarement définitif, on peut surcharger des opérateurs et s'amuser avec le compilo un peu pour rendre le code plus "à son goût". L'aspect intéressant c'est l'aspect "philosophique" -- quoique, je n'utiliserais peut-être pas le mot "intéressant" pour la philosophie sur la supériorité/infériorité des propriétés par rapport aux bons vieux getters/setters.

[screetch]

Je ne faisais que répondre à des trucs comme:



Effectivement on changera pas d'avis.

disons que voila mon opinion :
écrit la documentation de la propriété size
écrit la documentation de la fonction resize() et de la fonction size()

[Mac LAK]

je crois que tu n'as pas compris le point de koala la, ni le mien.

C'est réciproque, on peut jouer longtemps comme ça...

il ne s'agit pas de documenter un bidule, il s'agit que le bidule soit auto-documenté, grâce a un nom non pas "a peu près" correct mais _exact_
resize() fait exactement ce que son nom indique.
size non, et a besoin d'une documentation.

Même pas : le "re" sous-entends que l'opération est une modification à chaud, et non pas une primo-allocation. Pour faire plus clair, c'est comme si tu me disais que tu utilises realloc à la place de malloc de façon constante. Le nom serait exact si c'était "setsize", et non pas "resize"... Et une documentation est nécessaire pour savoir si les éléments sont conservés ou pas : on va donc l'appeler "setsizewithelementconservationexceptifsizeisreduced"... Ouais, super.

operator[] n'est pas clair non plus. la preuve ? tu t'es trompé dans sa description.

Mmm ?? Dis-moi donc où, stp...

Je sens quand même un poil de mauvaise foi, ou peut être une indication de dissonance cognitive (va savoir ; je pencherais presque pour le second, tant il me parait plus honnête que le premier).

C'est plutôt que j'ai l'habitude de les utiliser, et que respecter mordicus Demeter produit, dans ma branche, des bouses infectes surmultipliant les couches, les interfaces et plombant les perfs : difficile donc d'y adhérer.
Côté perso, et dév de haut niveau, c'est plutôt des fonctions de très haut niveau, et les propriétés permettent une manière simple et pratique d'utiliser les classes : là encore, Demeter serait surtout une nuisance côté application finale, en alourdissant le code inutilement.

En quoi un accès à conséquences multiple à une unique entité est plus explicite qu'un accès à conséquence unique à de multiples entités ? En quoi est-ce différent du raisonnement humain de dire que resize() change la taille telle que donnée par size() ?

Si c'est la même chose, en quoi le définir en accès unique est-il un problème ?
Avoir l'équivalent, en terme d'unicité d'accès, sans utiliser de propriétés revient à déclarer une sous-classe très fortement imbriquée dans sa classe parent, contrôlant justement tous les aspects liés à la taille.
C'est plus simple dans le sens où tu n'as qu'un seul accès pour un concept donné, donc inutile de chercher à côté s'il existe autre chose : tout est là.
Je ne vois pas en quoi écrire "myClass.Size = 20 ;" est difficile à comprendre d'un point de vue syntaxique, ou même sémantique... La taille du machin est mise à 20, point, c'est simple et net.

A mon avis, mais je peux me tromper, tu confonds simplicité et simplisme.

Non, c'est surtout que je suis assez souvent amené à créer des librairies, les utiliser moi-même dans l'évolution commandée, et filer ensuite le bébé à quelqu'un d'autre pour la maintenance.
Via des interfaces simples, la plupart du temps, personne ne vient me poser de questions idiotes. Via des usines à gaz complexes privilégiant la sacro-sainte encapsulation à outrance, on vient me chercher à chaque fois que quelqu'un touche le code... Dans les deux cas, pourtant, je te promets que la doc est aussi correcte et complète que possible.

On se fait un petit plaisir, ne parlons pas de performance. <snip> C'est dans les deux cas le compilateur qui fait le sale boulot d'optimisation

C'est en partie vrai seulement, mais admettons, pour des cas relativement simples tout du moins.

La "centralisation" (je pense que je vois ce que tu veux dire) n'est pas un but en soi.

Pour le développeur ? Bien entendu... La philo Unix est même basée sur un principe similaire, d'ailleurs. Mais pour l'utilisateur, par contre, non : c'est au contraire quelque chose de crucial.
Si tu veux une analogie, c'est la différence entre une aide façon Windows (avec index, recherche, etc.) et une aide façon manpage. Dans le premier cas, tu peux chercher en fonction du but désiré. Dans le second, il vaut mieux connaître le nom de la fonction pour en avoir l'aide.

Pour ma part, j'ai les deux casquettes à la fois : je développe des API pour les autres, et j'en utilise moi-même (y compris les miennes, bien sûr). Je sais aussi que ça vaut le coup de passer 5% de temps de plus sur le dév, pour faire de "l'inutile" fonctionnel, mais qui me permettra d'avoir une paix royale par la suite sur l'utilisation.

lisibilité : une propriété représente quelque chose d'intrinsèque à l'objet. <snip> Mélanger définition et traitement dans une même section de code rends le code plus difficile à déchiffrer.

Côté code interne à la classe ?? Mais quel besoin as-tu d'y mettre les mains pour l'utiliser, de façon générale ?? Quant aux données intrinsèques... C'est impossible d'avoir, de façon constante et systématique, l'absence totale de publication d'éléments intrinsèques. La taille d'un container devra forcément être publiée d'une façon ou d'une autre, un itérateur est une manière également de parcourir la structure interne d'une classe, etc. Si l'on raisonne sur le FOND et non pas sur la FORME, l'exposition de données intrinsèques est obligatoire.

Pour le reste, j'ai plus de facilité à suivre les données que les actions, au contraire. Heureusement, la plupart des informaticiens sont à peu près bons en maths.
Pour les non-informaticiens, j'ai souvent moins de mal à leur représenter les concepts inclus dans une classe sous forme d'entité pouvant être manipulée que sous forme d'actions élémentaires incluses dans la classe parent.

expressivité : une fonction fait une chose unique (dans l'idéal). Une propriété peut être accédée de manière différente (par exemple en lecture et en écriture).

Heu... Ne me dis pas que tu ne distingues pas une L-Value d'une R-Value, quand même. Ce n'est pas la même chose de lire et écrire une entité, même si ce sont bien entendu des opérations complémentaires. Je ne vois pas en quoi son rôle n'est pas unique... Tout comme une fonctionnalité peut être effectuée de plusieurs manières différentes sur les containers STL, par exemple : tu peux faire un erase() ou un resize(0), c'est pareil : où est l'unicité de la fonction, dans ce cas ??

L'utilisation d'un nom unique réduit d'autant l'expressivité de ce nom - par rapport à l'utilisation de plusieurs noms différents, chacun lié à une action particulière.

Ou le contraire : ça t'évite d'avoir plusieurs noms redondants pour décrire un concept unique. A condition d'arrêter de voir une propriété comme un attribut bête et méchant, et de la prendre en tant que concept, bien sûr.

Une propriété n'est PAS un attribut, même si elle s'utilise de la même manière. Ce serait aussi idiot que de dire qu'une fonction C et une fonction macro (préprocesseur) sont la même chose, juste parce qu'elles ont des parenthèses et des paramètres.

On peut argumenter sur le fait que les propriétés ne servent à rien. Dans l'ideal, il devrait être possible d'écrire un programme sans accesseurs et sans mutateurs, et donc sans propriétés. Un conteneur n'a pas besoin d'avoir une propriété Size si je peux utiliser les algorithmes du conteneur (par exemple une méthode foreach(), ...).

Certes. Derrière, par contre, tu oublies que l'on a aussi des contraintes budgétaires, calendaires,techniques et humaines. OK, c'est idéaliste, mais c'est justement pour ça que ce n'est pas applicable. En pratique, ce n'est d'ailleurs pas de l'idéalisme, mais de l'utopie.

je pense que je peux y arriver, en tout cas pour certains problèmes simples, tout en respectant MON style de programmation).

Justement, tu as dis le mot : "simples"... Réussir à transformer une problématique complexe en un programme performant, on sait tous que c'est tout sauf trivial (et ceci que l'on soit collé au matériel ou dans les domaines de très haut niveau, d'ailleurs).
Le plus souvent, on arrive à un résultat performant, certes, mais difficile d'utilisation. Quel est le besoin qui pousse la plupart des dévs à se contenter de ceci, au lieu de simplifier les interfaces pour l'utilisateur et donc de "simplifier" le problème général pour celui qui utilise la boîte noire ??

Le projet n'est pas vraiment de taille mirobolante, mais c'est quand même un projet pro, avec les contraintes liées à ce type de projet.

Tout dépend de ce que tu appelles "taille mirobolante". Pour ma part, on est une vingtaine en permanence sur le projet, qui dure depuis presque 10 ans, et avec un turn-over énorme. Crois-moi, dans ce genre de cas, tu cherches au maximum à simplifier les interfaces d'utilisation, quitte à rendre le code interne (mais normalement caché) un peu plus difficile d'accès. De toutes façons, il est nettement plus souvent utilisé que modifié, donc ça convient très bien de privilégier l'utilisation à la modification.



D'un point de vue "conception interne de la classe et méthodes à développer", les propriétés ne simplifient RIEN. Par contre, elles simplifient l'utilisation de la classe, en centralisant les points d'accès et en simplifiant les appels. Ce n'est que de la syntaxe, la sémantique est très exactement la même que les accesseurs, mutateurs ou attributs suivant ce que l'on décide de mettre en propriété. Cela ne t'empêche pas de faire ce que tu veux (elles n'ont rien d'obligatoire), et permet de méchamment simplifier des interfaces qui pourraient devenir franchement infectes. Bref, où est le problème ??

Là, j'ai l'impression de voir un remake du bon vieux troll "caster le malloc en C" : on hurle sur quelque chose qui ne gêne que les puristes, simplifie la vie des utilisateurs (et je rappelle que l'on code pour que ce soit utilisé, hein, pas pour mettre en vitrine), et pour lesquels les "désavantages" sont des problèmes largement plus issus de la conception que de l'implémentation...

[screetch]

Blague à part : taper dans une map de la STL se fait également via [], simplement tu n'as pas toute la finesse de contrôle qui est possible via find/insert. Et alors ? Les exceptions existent pour ça, ce sont effectivement des comportements non-nominaux de tenter de récupérer un élément inexistant et/ou d'écraser un existant, mais ça peut parfaitement convenir à la plupart des besoins.

de plus je ne vois pas le rapport avec find

[koala01]

Et alors ? Si c'est en lecture seule, ça n'a aucune importance, sauf celui de te permettre d'avoir du code d'introspection.
Si c'est en écriture, tu as des tonnes de mécanismes permettant de blinder cet aspect (sections critiques, enregistrement via par exemple le TLS, encapsulation et/ou private implementation, singletons, pointeurs avec compteur de référence, et j'en passe).

C'est justement là le problème...

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.

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

Comme les propriétés, même si elles permettent le choix de l'acces qu'elles autorisent, sont, par défaut, d'accès "global" (comprend: accesssible depuis n'importe quel endroit du code, même s'il y a des conditions à remplir), 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.

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

Rien ne t'oblige à publier 100% de tes attributs dans des propriétés RW, ni à remplacer le concept d'attribut par celui de propriété.
Une propriété est une interface de la classe : si quelque chose ne doit pas être manipulé de l'extérieur, pourquoi diable voudrais-tu en faire une propriété ???

Le problème, c'est, encore une fois, que, à faciliter la mise en oeuvre de chose dont l'usage devrait à chaque fois être décidé après mure réflexion, tu n'incite les gens à créer des propriétés "par habitude", y compris pour des attributs qui n'ont nul besoin d'être représenté sous cette forme, et, pire encore, tu encourage le développeur (vu que c'est l'une des possibilités de la propriété) à 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.

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...

Pas plus qu'un accesseur... C'est très exactement la même chose, seul l'utilisateur voit une différence réelle entre les deux.

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...

Avec une propriété, si... Du moins, c'est l'impression qu'aura l'utilisateur.

Et c'est presque plus un risque qu'un avantage...

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

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 )

Et tu connais surement tout aussi bien la loi de murphy, qui dit que, s'il est possible de faire une connerie, tu trouvera toujours quelqu'un pour la faire.

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.

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

Tu me reparles de multiples fonctions de redimensionnement, moi je te parle d'un concept unique de taille (ou capacité, si tu préfères). Cela n'empêche absolument pas d'utiliser une méthode Add() pour ajouter un élément, wrappant au besoin un sous-container. Quand aux fonctions de modification de taille, il est souhaitable qu'elles existent de façon unitaire (erase(), resize(), incsize(), decsize(), que sais-je encore...) et qu'elles soient utilisées au sein de l'interface "Write" de la propriété, en fonction de la valeur passée en paramètre.

Oui, si tu y tiens, rajoutons incsize et decsize... bien que je ne les ferais pas apparaitre dans l'interface publique (ne serait-ce que pour des problèmes d'initialisation de l'élément ajouté par incsize )

Bref, c'est à toi de t'assurer que tu respectes ton contrat, c'est à dire que ta taille a été augmentée d'une unité après un ajout... Le formalisme utilisé (méthodes ou propriété) n'a absolument aucune importance, sauf pour l'utilisateur final qui y gagne en simplicité.

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"...

Un bête exemple, si l'auteur du code oublie le deuxième = lorsqu'il utilise la propriété "size" à l'intérieur d'un test, il aura modifié la taille de la collection, sans s'en apercevoir, et avec des conséquences pouvant être catastrophiques

Je trouve plus confusant d'avoir N points d'accès à un concept donné (ex : la capacité d'un container) au lieu d'un seul et unique, dont la valeur ou le cadre d'utilisation (L/R-Value) est proche de la représentation "humaine" dudit concept. Une taille/capacité se lit, se détermine, peut augmenter, diminuer, être réduite à néant. C'est une formalisation assez proche de ce que l'on trouve fréquemment dans les spécifications de besoin, en fait.

Il n'y a rien de confus, et il n'y a même pas plusieurs point d'acces à un concept unique:

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

Blague à part : taper dans une map de la STL se fait également via [], simplement tu n'as pas toute la finesse de contrôle qui est possible via find/insert. Et alors ? Les exceptions existent pour ça, ce sont effectivement des comportements non-nominaux de tenter de récupérer un élément inexistant et/ou d'écraser un existant, mais ça peut parfaitement convenir à la plupart des besoins.

Pourquoi s'emm.... avec un itérateur et des méthodes find/insert, alors que l'on contrôle en amont ce qui est lu/écrit dans la map, et que les exceptions (cas anormal et rarissime) conviennent parfaitement à la gestion des erreurs ? L'opérateur [] fait parfaitement l'affaire, est cent fois plus simple à utiliser, et répond au besoin. Utiliser autre chose, c'est simplement aimer se compliquer la vie pour rien.

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...

Pour toi, peut-être. Pour moi, c'est un index, ni plus, ni moins, avec des limites hautes et basses et (par défaut) pas de "trous" dans son domaine. Son caractère aléatoire et/ou direct m'importe peu.

Peut être n'est ce que pour moi, mais, même si ce n'est que du à la force de l'habitude du C, j'estime que, bien que le fait qu'il permette d'avoir des limites hautes et basses, sa principale qualité tient, justement, dans le type d'acces aux différents éléments...

Je le vois comme "méthode pratique et basique d'accès", ni plus, ni moins. Je ne pars pas du principe que c'est l'accès le plus performant (même si c'est souvent le cas), je pars du principe que c'est le plus PRATIQUE. C'est très différent.

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

Heu... On ne doit pas avoir le même sens pour sémantique (="le fond"), que j'associe en général au mot "syntaxe" (="la forme").
La sémantique, c'est l'opération à effectuer (récupérer un élément, avoir la taille du container, etc.). La syntaxe, c'est la forme que cela prends (propriété, méthode, accesseur, service réseau, glutz vénusien...).

La sémantique, c'est le sens que l'on donne (de manière conventionnelle ou consensuelle) à un terme.

C'est ce qui te permet de ne pas recevoir un couteau ou une fourchette lorsque tu demande une cuiller.

Si un terme a un double (ou pire, un triple/quadruple/... sens), il ne faut pas t'étonner si, à un moment donné, les gens se trompent sur le sens qu'il fallait donné à ce terme, c'est aussi simple que cela...

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

Encore heureux que les fonctions s'adaptent aux circonstances : comment voudrais-tu faire de la gestion d'erreurs sans ça ???
Sans même parler des surcharges de méthodes...

Je pense que tu as voulu dire autre chose que ce que je suis en train de lire : peux-tu reformuler, stp ?

Elles s'adaptent au circonstances, mais gardent des comportement dont le but estfondamentalement identique...

Il est bien évident que, dés que tu as un test ou une boucle, ta fonction s'adapte aux circonstances, mais le but recherché par ta fonction est... fondamentalement unique

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

Ce qui est le cas d'une propriété, clairement définie comme telle bien entendu, qui regroupe via un seul identifiant un concept complet telle que la taille / capacité d'un container, au lieu de disperser cette information sur N entités diverses.
Donc, un seul point à documenter / assimiler, et tu as l'accès à toutes les fonctions liées à un concept. Difficile de faire plus simple, plus concis et plus compréhensible, je trouve.

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.

Du point de vue de l'utilisation, je préfère avoir trois fonctions clairement distinctes pour lesquelles une simple phrase commençant par "cette fonction fait..." que d'avoir un "concept" (quelque part fort élargi ) et devoir me rappeler de... tous les cas d'utilisation (si je fais ceci, j'aurai tel résultat, mais si je fais cela, j'aurai tel autre résultat, et, si d'aventure, j'ai une troisième possibilité, j'aurai encore quelque chose d'autre)

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

Ca fait cher payé pour un caractère oublié, non

Des concepts comme les propriétés permettent de rendre les classes plus "intelligentes", sans pour autant complexifier leur interface publique, ni les rendre spécialement moins performantes, ni spécialement plus longues à écrire. Pour ma part, je trouve que ça va dans le bon sens, étant donné que développeur comme utilisateur y gagnent.

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...

Bon, désolé du pavé, mais t'es au moins "aussi pire" que moi au niveau longueur des posts...

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

[Mac LAK]

de plus je ne vois pas le rapport avec find

Tu peux lire/écrire dans une map via [], simplement ça jette une exception si l'élément n'existe pas (en lecture), et ça ne dit rien si tu l'écrases un élément existant (en écriture).

Via find, tu peux vérifier l'absence de l'élément lorsque tu le cherches, sans produire d'exception. Via find + insert, tu peux ne pas écraser un élément existant. C'est donc plus "fin" en terme de possibilités, mais ce n'est pas toujours utile d'aller aussi loin.

Donc, d'un côté, tu as un cas d'utilisation dans ce genre :

Code :

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

1
2
3
4
5
        CmyMap::iterator iter_l = myMap.find(KeyData);
        if (iter_l!=myMap.end())
            PairValue = iter_l->second ;
        else
            throw std::range_error("......");

De l'autre, tu as :

Code :

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

        PairValue = myMap[KeyData] ;

Les deux sont tout à fait équivalents... Le second est quand même nettement plus lisible.

[screetch]

c'est quoi un CMyMap???
parce que sinon, non, ca ne fait pas ca du tout
operator[k] renvoie une référence sur la valeur associée a la clé k, si la valeur n'existe pas alors une valeur par défaut est d'abord insérée puis renvoyée.

il n'y a jamais besoin d'utiliser find() pour insérer, find c'est pour trouver, pas pour insérer.

insert() insère l'élément (le couple clé-valeur) si il n'existe pas, et renvoie le résultat
pas d'exception, non...

[Emmanuel Deloget]

Je regrette mais non, pas du tout. Les propriétés permettent justement d'être expressif là où on ne peut pas avec des appels de fonctions.
Si le même nom existe pour la lecture et l'écriture ET que la séquence d'action est cohérente, alors on est plus expressif (transmettre l'idée). Avec un coût

Pour un exemple imaginaire où vous mourrez d'envie d'agrandir de 4 la place disponible dans un tableau:

En D:

Code :

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

1
2
3
4
 
A[] tableau;
...
tableau.size = tableau.size + 4;

et même depuis quelques temps :

Code :

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

1
2
3
4
 
A[] tableau;
...
tableau.size += 4;

En C++:

Code :

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

1
2
3
4
 
std::vector<A> tableau;
...
tableau.resize (tableau.size() + 4);

Quelle version est plus lisible et plus expressive ? Vous trouvez peut-être le C++ plus lisible car vous êtes familier avec, mais c'est tout.
.

Diantre ! Donc, dans certains cas, on arrive à une expressivité que certains, en se basant principalement sur une définition approximative de la notion d'expressivité, jugent vaguement similaires

Il convient, lorsqu'on présente des contre-arguments à une argumentation, de bien comprendre les mots que l'autre a utilisé. Je ne dis pas ça pour être agressif ou quoi que ce soit. Il m'arrive de passer du temps à choisir mes mots - et pour ceux que j'ai utilisé, notamment "cohérence" (absence de contradiction) "expressivité" (voir ci-dessous) et "lisibilité" (qualité de ce qui est aisé à lire, à déchiffrer), j'ai eu la grandiose idée de vérifier leur sens exact dans un dictionnaire avant de poster (pour ceux qui on un iPhone, je recommande l'application Littré, qui est gratuite), notamment parce qu'on a beau les utiliser régulièrement, ça ne veut pas dire qu'on les utilise à bon escient (et quand je dis "on", je me mets dans le lot). C'est entre autre la raison pour laquelle mon post est arrivé si tard dans la discussion (16h38 alors que j'ai commencé de l'écrire à 13h15). Ce post même a été commencé à 17h20 environ - mais comme j'estime que j'ai le devoir de vérifier que mon argumentation tiens la route, je mets un peu de temps pour l'écrire.

Etre expressif ne signifie pas "faire beaucoup en peu". Etre expressif, selon le Littré, signifie "qui a la vertu de bien exprimer" - autrement dit, qui est clair - pas forcément concis. Wiktionnaire en rajoute une couche : qui exprimer bien la pensée, le sentiment.

Personne (enfin, pas un programmeur qui a un tant soit peu connaissance de la syntaxe C-like orienté objet, type C++, C# ou Java) ne peut prétendre ne pas comprendre ce que fait ta dernière version - qui est certes plus verbeuse mais qui a le mérite de décrire avec précision ce qu'elle fait.

Les deux versions que tu présentes par ailleurs nécessitent par contre de savoir entre autre que changer la propriété taille change effectivement la taille du tableau (ce n'est dit nulle part, et ce n'est absolument pas implicite ; si on arrive à penser que c'est effectivement ce qui se passe, c'est plus une question d'instinct que de connaissance. Relire "One story, two rules, and a BSP renderer" de M. Abrash (PDF) pour quelques leçons sur les effets de l'utilisation de l'instinct dans le métier de développeur. En tout état de cause, on ne peut pas prétendre que ce code est expressif, puisqu'il ne dit pas ce qu'il fait).

Dans ce cadre, je peux me permettre de ne pas être en accord avec toi : non, l'utilisation d'une propriété en lieu et place de l'utilisation de fonctions nommées spécifiquement pour effectuer une tâche particulière n'est pas suffisamment expressif.

A noter que System.ArrayList<> du framework .Net ne contient pas de propriété accessible en écriture et permettant de modifier la taille du tableau (la taille n'est modifiable que par l'utilisation de Add() et Insert()). La propriété Count est une propriété en lecture seule - je ne vois pas en quoi elle diffère de std::vector<>::size() et ce qu'elle apporte en plus...

Je reviens en outre sur ça :

Qui plus est en C++ je vais évidemment lire la doc vu que resize appelle un constructeur par défaut sur chaque nouvel élément alloué, et que ca a des implications...

Parce que tableau.size += 4 ne va pas faire ça du tout. Ca va probablement créer les nouveaux objets du tableau en utilisant des molécules présentes dans l'air ambiant, je suppose

Si je n'avais rien à faire de l'expressivité, j'écrirais du COBOL.

Etant donné que le problème de COBOL est sur la lisibilité, pas sur l'expressivité, tu peux quand même faire du COBOL et rester expressif. "Fort heureusement", tu peux aussi utiliser des propriétés en COBOL (version en cours de standardisation). Un exemple ici. Comme quoi ce langage évolue dans le bon sens...

[Invité]

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

J'ai bien aimé cet exemple, mais en fait on peut éviter cette erreur-là en renvoyant void depuis les mutateurs. Du coup, ca ne peux pas arriver.

Ca à l'air de marcher en C++ aussi, tu peux renvoyer void avec l'operator=.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class A
{
public:
    int x;

    A(int _x) : x(_x) { }

    void operator=(const A& a)
    {
        return *this = a;
(EDIT) en fait pas besoin de ce return
    }

};

Testé sous GCC, le if est refusé.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
int main(int argc, char* argv[])
{
    A a(1);
    A b(1);
    if (a = b)
    {
        // detection de l'erreur à la compilation
    }
}

[Mac LAK]

c'est quoi un CMyMap???

Tu le fais exprès... un std::map<typequelconque1,typequelconque2>, c'est si difficile que ça à comprendre ?

operator[k] renvoie une référence sur la valeur associée a la clé k, si la valeur n'existe pas alors une valeur par défaut est d'abord insérée puis renvoyée.

Autant pour moi : je viens de vérifier, c'est une vieille STL que l'on a sur une cible qui jette une exception si la clé n'existe pas. Ce qui ne change pas fondamentalement le principe : utiliser [] est nettement plus court que de se fader un find et son itérateur...

il n'y a jamais besoin d'utiliser find() pour insérer, find c'est pour trouver, pas pour insérer.

Et sans find (ou []), tu fais comment pour ne PAS écraser une valeur existante ??


@Koala : je te réponds un peu plus tard.

[screetch]

insert fait ce qu'il dit : il insère, point barre. il n'ecrase pas.
Et cela montre bien ce que je voulais dire : operator[] est plus concis mais tu ne sais pas ce qu'il fait, tu t'étais planter, d'où l'importance d'un nom correct de fonction.
c'est le point que l'on voulait mettre en avant, emmanuel, koala et moi.

[koala01]

J'ai bien aimé cet exemple, mais en fait on peut éviter cette erreur-là en renvoyant void depuis les mutateurs. Du coup, ca ne peux pas arriver.

Ca à l'air de marcher en C++ aussi, tu peux renvoyer void avec l'operator=.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class A
{
public:
    int x;
 
    A(int _x) : x(_x) { }
 
    void operator=(const A& a)
    {
        return *this = a;
    }
 
};

Testé sous GCC, le if est refusé.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
int main(int argc, char* argv[])
{
    A a(1);
    A b(1);
    if (a = b)
    {
        // detection de l'erreur à la compilation
    }
}

Mais, encore une fois, tu change la sémantique d'un opérateur...

operateur = est, par définition, l'opérateur d'affectation, et, en tant que tel, son prototype doit... renvoyer une référence sur l'objet en cours...

[EDIT]C'est bizare, mais, je fonctionne aussi avec gcc et, si j'essaye de donner un type de retour void à mon opérateur =, j'ai un joli

Code :

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

D:\projects\TestC++\main.cpp|10|error: return-statement with a value, in function returning 'void'|

[/EDIT]

En plus, tu te goure durement dans l'implémentation que tu en donnes...

[Goten]

J'ai bien aimé cet exemple, mais en fait on peut éviter cette erreur-là en renvoyant void depuis les mutateurs. Du coup, ca ne peux pas arriver.

Ca à l'air de marcher en C++ aussi, tu peux renvoyer void avec l'operator=.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class A
{
public:
    int x;
 
    A(int _x) : x(_x) { }
 
    void operator=(const A& a)
    {
        return *this = a;
    }
 
};

Testé sous GCC, le if est refusé.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
int main(int argc, char* argv[])
{
    A a(1);
    A b(1);
    if (a = b)
    {
        // detection de l'erreur à la compilation
    }
}

*this = a ? >_< ... kaboum

Et retourner void c'est bien jolie mais tu perds la sémantique, et en passant la possibilité de chainage...

[JolyLoic]

[je parlais de WPF]
Ce qui pour moi est rédhibitoire pour faire des IHMs. C'est certes bien mieux que les MFC, mais c'est loin d'être parfait ou du niveau d'un vrai RAD. Et il se pose le problème (plus ou moins épineux) de la connexion avec des DLL natives : autant certains cas de figure sont très simples, autant d'autres sont franchement galères vu l'impossibilité de franchir (via debug) la barrière entre le natif et le managé.

Je ne te disais pas de l'utiliser, mais de le regarder. Je trouve qu'i lpossède un niveau d'organisation du code qui va plus loin que ce que j'ai vu avec la VCL, les winforms, Qt (je n'ai pas ragardé les versions récentes)... et qu'il permet une productivité dans la flexibilité comme dans l'usage de base que ces produits n'offrent pas.
Maintenant, s'il pouvait exister un framework genre wpf en C++ (bien que tu exagères les difficultés de debug, la barrière managé/natif étant assez transparente de ce point de vue là), je m'y pencherais sûrement.

[Invité]

Bravo pour les références au Littré et Wiktionnaire, il est dommage que le contenu qui suit soit un peu décevant.

Etre expressif ne signifie pas "faire beaucoup en peu". Etre expressif, selon le Littré, signifie "qui a la vertu de bien exprimer" - autrement dit, qui est clair - pas forcément concis. Wiktionnaire en rajoute une couche : qui exprimer bien la pensée, le sentiment.

Personne (enfin, pas un programmeur qui a un tant soit peu connaissance de la syntaxe C-like orienté objet, type C++, C# ou Java) ne peut prétendre ne pas comprendre ce que fait ta dernière version - qui est certes plus verbeuse mais qui a le mérite de décrire avec précision ce qu'elle fait.

Quelle précision a t'elle en plus ?
Pour quelqu'un qui connait le D, les deux premières sont aussi compréhensibles et complètes que la troisième pour quelqu'un qui fait du C++.
Ce que tu veux dire, c'est que la troisième est plus expressive car c'est du C++ et que tout le monde connait le C++. Deux poids, deux mesures.

Parce que tableau.size += 4 ne va pas faire ça du tout. Ca va probablement créer les nouveaux objets du tableau en utilisant des molécules présentes dans l'air ambiant, je suppose

En fait j'avais écris cet exemple dans un contexte D, où le problème ne se poserait pas. Mais oui, une propriété C++ ca ferait pareil que resize.

Ce que je voulais dire:
En C++, je peux tomber sur un constructeur par défaut redéfini qui lancerait des exceptions pour échouer... (c'est un scénario catastrophe évidemment)

A noter que System.ArrayList<> du framework .Net ne contient pas de propriété accessible en écriture et permettant de modifier la taille du tableau (la taille n'est modifiable que par l'utilisation de Add() et Insert()). La propriété Count est une propriété en lecture seule - je ne vois pas en quoi elle diffère de std::vector<>::size() et ce qu'elle apporte en plus...

A mon avis ils ont fait ça car utiliser la propriété Capacity est une meilleure idée dans ce cas (qui elle est RW).

[Invité]

*this = a ? >_< ... kaboum

Et retourner void c'est bien jolie mais tu perds la sémantique, et en passant la possibilité de chainage...

On m'objecte un problème improbable, j'y réponds une réponse improbable.