L'avenir du C++

A chaque fois qu'on a besoin d'un mot clef, le choix se pose d'en prendre un existant et de le détourner de son utilisation courante (quitte à ce que ce ne soit pas clair, voir static par exemple), trouver une syntaxe sans mot clef (de moins en moins facile), ou en prendre un nouveau (tant pis pour les programmes qui les utilisaient avant...).

Dans ce dernier cas, il y a souvent des recherches effectuées sur des moteurs de recherche de code pour choisir le moins utilisé entre les alternatives possibles.

Voir par exemple http://www.open-std.org/jtc1/sc22/wg...006/n2105.html pour plus d'infos.

Merci pour le lien, très intéressant!
C'est vrai que ça pose problème. Mais d'un autre côté, on ne peut que très rarement faire autrement que de rajouter un mot clé.
Par exemple decltype(ou auto), comment faire?
Moi j'aurais bien vu

Code:

---

<>(2+3) i; // crée un int nommé i

---

Ou bien

Code:

---

<2+3> i; // de même ...

---

On pourrait même prendre sa valeur à cette endroit, dans certains cas.

Bon en même temps cela va bientôt faire 24 heures que je n'ai pas dormi.
:aie:

Citation:

---

Envoyé par JolyLoic

tant pis pour les programmes qui les utilisaient avant...

---

C'est vrai que comme disait ma grand-mère on fait pas d'omelette sans casser des oeufs, je suppose qu'on ne fait pas évoluer un langage comme le c++ sans causer quelques désagréments :mouarf:

Pour ce qui est de "where" devenu "requires<>" ça ne serait pas justement pour inclure plus tard des instructions SQL comme le fait C# 3.0 ?

Citation:

---

Envoyé par Alp

Moi j'aurais bien vu

Code:

---

<>(2+3) i; // crée un int nommé i

---

---

C'est plus ou moins la syntaxe des fonctions lambda ça.

Oui oui, tout à fait. C'est d'ailleurs en pensant à ça que j'ai écrit ces codes.
L'idée serait de pouvoir généraliser ça aux types.

Quelqu'un est au courant si ils ont rajouté des mots clef ou une syntaxe a la C# pour les accesseurs ?
Je sais que avec les éditeurs actuels se n'est pas indispensable, mais je suis acro a VI :aie: et de me les palucher tous un par un c'est une peu barbant... :mrgreen:

Citation:

---

Quelqu'un est au courant si ils ont rajouté des mots clef ou une syntaxe a la C# pour les accesseurs ?

---

C'est-à-dire ?

Autan que je sache, en C# on peut faire ceci :

Code:

---

1 2 3 4 5 6 7 8 9

public string title { // Propriete get { return title; } set { title = value; } }

---

et ensuite quand on affecte la propriété title cela appelle automatiquement le bloc 'set' et idem quand on désire récupérer la valeur de celui-ci avec le bloc 'get'
Du moins d'après ce que j'ai compris... le C# n'est pas ma tasse de thé :aie:

Tu parles peut-être des "properties", qui permettent d'appeler des fonction "get" ou "set" avec une syntaxe proche de l'accès à une variable ?

Si tel est le cas, il n'y a rien de prévu de la sorte actuellement.

Citation:

---

Envoyé par baptistoux

et ensuite quand on affecte la propriété title cela appelle automatiquement le bloc 'set' et idem quand on désire récupérer la valeur de celui-ci avec le bloc 'get'
Du moins d'après ce que j'ai compris... le C# n'est pas ma tasse de thé :aie:

---

Regarde les objets ATL-COM sous VC++ c'est rigoureusement identique...
si tu fais un projet Active X sous VC++ tu as des getters /setters
.NET n'est ni plus ni moins qu'un COM amélioré avec Garbage Colector ( repompé sur Java )

Citation:

---

Envoyé par baptistoux

Quelqu'un est au courant si ils ont rajouté des mots clef ou une syntaxe a la C# pour les accesseurs ?

---

?
Je crois qu'une révision des bases du C++ s'impose; prends un bon livre de base sur le C++ tu verras que cela existe déjà.
D'ailleurs get/set c'est à mon gout très casse-pied à gérer et entraine du code totalement inutile

Citation:

---

Envoyé par Mat.M

?
Je crois qu'une révision des bases du C++ s'impose; prends un bon livre de base sur le C++ tu verras que cela existe déjà.
D'ailleurs get/set c'est à mon gout très casse-pied à gérer et entraine du code totalement inutile

---

Hum, sa question n'était pas ininterressante, les properties à la C# sont assez pratique. Il parrait même que Sun envisage une fonctionnalité similaire pour le Java. Mais de la à dire que ça existe déja,... ce n'est jamais que le même bricolage qu'il est possible de faire dans tous les langages. Sois dit en passant, cette fonctionnalité est justement faite pour que ce soit moins casse-pieds malin :)

Citation:

---

Envoyé par zais_ethael

Hum, sa question n'était pas ininterressante, les properties à la C# sont assez pratique.

---

C'est du sucre syntaxique. Et on sait que

Citation:

---

syntactic sugar causes cancer of the semicolon

---

Blague a part, j'ai pas encore compris l'utilite. C'est quoi, de mentir sur la nature d'une operation?

L'utilité première est d'obtenir du code plus proche d'une notation mathématique "naturelle". C'est surtout pour des IMH, où une classe a typiquement pas mal de propriétés, que je trouve cette notation pratique. Qu'est-ce qui est le plus léger à la lecture ?

Code:

---

1 2 3 4 5

dialogue.setLargeur(widget.getLargeur() + espace + bouton.getLargeur()); dialogue.set_Largeur(widget.get_Largeur() + espace + bouton.get_Largeur()); dialogue.Largeur(widget.Largeur() + espace + bouton.Largeur()); dialogue.setLargeur(widget.Largeur() + espace + bouton.Largeur()); dialogue.Largeur = widget.Largeur + espace + bouton.Largeur;

---

Avantages :
- Moins de parenthèses à apparier lors de la lecture
- Plus besoin de se mettre d'accord sur une convention de nommage (et de devoir vivre avec plusieurs conventions de nommage différentes qui cohabitent) pour les accesseurs
- Peut servir de base pour des outils de génération de code (genre QtDesigner) dont l'IHM présente des propriétés sémentiquement plus proches de variables que l'on positionne que de fonctions que l'on appelle.
- Plus grande rapidité du prototypage, moins de code à écrire, puisqu'on peut directement exposer des données membre de sa classe, sans les mettre en private, puisqu'on sait que le jour où l'on aura besoin de faire des choses supplémentaires lors de la lecture/écriture de la donnée, ou pourra basculer vers cette notation sans changer une seule ligne du code client.

Inconvénients :
- Syntaxe supplémentaire, nécessitant probablement de nouveaux mots clef.
- Le fait que ce qui ressemble à un simple accès à une donnée puisse cacher des traitements peut être ressenti par certains comme de l'obfuscation, et une source de problèmes de performance.

Comme on peut le voir, je suis pour ma part plutôt pour, mais je ne considère pas ça comme indispensable.

Citation:

---

Envoyé par JolyLoic

L'utilité première est d'obtenir du code plus proche d'une notation mathématique "naturelle". C'est surtout pour des IMH, où une classe a typiquement pas mal de propriétés, que je trouve cette notation pratique. Qu'est-ce qui est le plus léger à la lecture ?

---

C'est peut-être à cause du domaine -- je n'ai pas tellement touché aux IMH jusqu'à présent --, mais quand j'ai des paires setters/getters, j'ai l'impression d'avoir manqué quelque chose dans le design. Je ne suis a priori pas favorable à une syntaxe qui les rend plus légers.

Dans l'exemple que tu donnes, j'ai plutôt l'impression que ce qui va gérer la largeur du dialogue, c'est un gestionnaire de géométrie qui va se comporter de manière un peu plus complexe, ne fut-ce que pour être capable de gérer un nombre quelconque de widgets. Et je n'ai pas du tout envie que quelqu'un se mette à écrire:

Code:

---

1 2 3 4 5

dialog.Largeur = 0; for (i = dialog.widgets().begin(); i != dialog.widgets().end(); ++i) { dialog.Largeur += i->Largeur; }

---

Sans se rendre compte que la largeur des widgets est modifiée par effet de bord quand on change la largeur du dialogue... (c'était le cas dans les IMH que j'ai utilisée)

Citation:

---

Envoyé par baptistoux

Quelqu'un est au courant si ils ont rajouté des mots clef ou une syntaxe a la C# pour les accesseurs ?
Je sais que avec les éditeurs actuels se n'est pas indispensable, mais je suis acro a VI :aie: et de me les palucher tous un par un c'est une peu barbant... :mrgreen:

---

Ben ... passe à vim et utilises ma suite de ftplugins pour le C et le C++
:P

Mais bon. Si c'est juste pour lire ou modifier une valeur sans faire aucune vérification, ni même propager aucun événement à des observateurs, l'intérêt est des plus limités.

Sinon, dans le passé il y avait eu un papier faisant un état de l'art sur les moyens et techniques à notre disposition pour définir des propriétés en C++. Il y avait même eu une proposition d'extention du langage -- pas validée si je comprends bien.

Tout cela pourrait être aisement résolu si C++ adoptait une bonne manière de surcharger l'opérateur point.

On peut avoir l'illusion en définissant des membres publics d'une classe définissant l'opérateur= et des conversions implicites de manière adéquate. Mais je n'ai toujours pas compris l'intérêt de favoriser les setter/getter.

L'interet, comme le cite si bien JolyLoic:

Citation:

---

Envoyé par JolyLoic

Plus grande rapidité du prototypage, moins de code à écrire, puisqu'on peut directement exposer des données membre de sa classe, sans les mettre en private, puisqu'on sait que le jour où l'on aura besoin de faire des choses supplémentaires lors de la lecture/écriture de la donnée, ou pourra basculer vers cette notation sans changer une seule ligne du code client.

---

Dans un design fortement orienté OO, où nous ferons une utilisation intensive d'interfaces à implémenter, il n'est pas juste d'obliger les futures implémentations à contenir un champ d'un type donné. Tout ce que contiendra en général une interface est une indication comme quoi il existe une propriété en lecture/ecriture ou en lecture seule. En effet, une propriété donnée peut très bien être calculée à la demande, être contenue non pas directement dans l'objet mais dans un autre objet, etc...
Cela fini par donner des situations telles que le Java, où on utilise pour toutes les classes un générateur de getters/setters. Sérieux, je programme depuis en bout de temps dans ce langage et je n'ai jamais vu une biblio de bonne qualité mettre un champ en public. L'interet du C# est que la syntaxe est exactement la même depuis l'extérieur de la classe si il s'agit d'un bête champs déclaré public ou d'un accesseur personnalisé. Donc on est jamais obligé d'utiliser un générateur.
Toujours pour le Java, il existe un petit débat pour savoir si ces accesseurs devraient être ajoutés au langage. Même si le manque est évident je ne suis pas trop d'accord -> le langage n'ayant pas été conçu pour ça dés le départ, les seules solutions qui sont proposées sont alambiquées et dénaturent la syntaxe.
Pour le C++ c'est encore pire. Non seulement la syntaxe est déja assez alambiquée comme ça mais c'est un langage qui n'est pas full objet, la plupart du temps on cherche une autre alternative. Donc pour répondre à la question de baptistoux, c'est sur que dans l'absolu c'est une bonne chose mais en C++ ça ne serait pas très utile.

Citation:

---

Envoyé par zais_ethael

L'interet, comme le site si bien JolyLoic

---

Ca c'est l'intérêt d'une syntaxe légère une fois qu'on a décidé qu'on en avait besoin. Je me plaçais au temps précédent: quel est l'intérêt de favoriser les designs avec setters/getters. Leur utilisation me semble généralement résulter d'une mauvaise conception.

ça se ferait très bien en C++ si on disposait de surcharge de l'opérateur point (la fonction prendrait en fait une chaîne de caractères "compile-time") et de reflexion à la compilation appropriée.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je me plaçais au temps précédent: quel est l'intérêt de favoriser les designs avec setters/getters. Leur utilisation me semble généralement résulter d'une mauvaise conception.

---

Ha bah, voila un avis bien tranché que j'ai beaucoup de mal à comprendre.
Si on considère une conception OO détachée du langage (pour faire simple: un modèle de classes UML, et on oublie le C++), en quoi peux-tu considérer que ce soit mal de mettre une propriété dans une classe? En sachant qu'une propriété est "un peu comme un attribut" mais en plus maléable, ce qui n'est pas pour déplaire au fans d'interfaces.

Citation:

---

Envoyé par loufoque

ça se ferait très bien en C++ si on disposait de surcharge de l'opérateur point (la fonction prendrait en fait une chaîne de caractères "compile-time") et de reflexion à la compilation appropriée.

---

Si ce n'est pas déja le cas ce n'est pas sans raison, je vois difficilement comment adapter un tel fonctionnement en C++. Mais même en admettant que ce soit possible je ne vois pas non plus en quoi ça faciliterait l'émulation d'accesseurs.

J'avoue que l'exemple que j'ai pris n'est pas forcément bien choisi, puisqu'il est vrai qu'en général la position des objets dans une boîte de dialogue dépend d'un gestionnaire de layout. Maintenant, dans une application de type dessin, ou l'utilisateur manipule les coordonnées des objets à la souris, ça peut avoir plus de sens.

Et pour des éléments plus standard d'une IHM, il y a pléthore de choses pour lesquelles une propriété avec ses accesseurs me semble l'abstraction naturelle. Par exemple, pour un bouton, le texte, l'icône, le style d'affichage, les couleurs (soit en RGB, soit en rôle dans une palette de couleurs)... Tous me semblent des chose que l'utilisateur peut vouloir lire ou modifier manuellement, à l'aide d'accesseurs.

J'ai joint une copie d'écran des propriétés exposées d'un bouton dans .NET. Il y en a peut-être quelques unes qui mériteraient un traitement plus global que par une propriété isolée, par exemple le numéro d'ordre pour le bouton tab, mais pour la plupart, cette notion me semble usuelle.
Pièce jointe 18373Pièce jointe 18374

En fait, en plus de l'IHM, il y a une autre catégorie d'objets pour lesquels la notion de propriété me semblerait une bonne chose, ce sont pour des petits objets, généralement des value types, qui semblent autant se définir par ce qui les compose que par un comportement.

Par exemple, un complexe me semble naturellement avoir quatre propriétés : real, imag, arg, abs. Une couleur me semble avoir les propriétés R, G, B et A. Une grandeur physique une valeur et une unité...

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je me plaçais au temps précédent: quel est l'intérêt de favoriser les designs avec setters/getters. Leur utilisation me semble généralement résulter d'une mauvaise conception.

---

Citation:

---

Envoyé par zais_ethael

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je me plaçais au temps précédent: quel est l'intérêt de favoriser les designs avec setters/getters. Leur utilisation me semble généralement résulter d'une mauvaise conception.

---

Ha bah, voila un avis bien tranché que j'ai beaucoup de mal à comprendre.
Si on considère une conception OO détachée du langage (pour faire simple: un modèle de classes UML, et on oublie le C++), en quoi peux-tu considérer que ce soit mal de mettre une propriété dans une classe? En sachant qu'une propriété est "un peu comme un attribut" mais en plus maléable, ce qui n'est pas pour déplaire au fans d'interfaces.

---

Les setter/getter donnent des objets une vision "collection d'attributs indépendants". J'arrive très rarement à ce genre d'objets.

Le seul exemple donné jusqu'à présent -- et je crains que sans exemples convainquant, je resterai sur ma position -- me semble être bien mauvais. Je suis très loin d'être un spécialiste des IHM, mais la taille d'un widget en contenant d'autres ne devrait pas être à mon sens quelque chose que n'importe qui peut modifier. A priori, la taille du widget de plus haut niveau n'est pas fixée par le programme (il peut en proposer une, mais ce n'est qu'une proposition) mais par l'utilisateur. Après, le programme fixe le placement des widgets contenu en fonction de la taille choisie par l'utilisateur.

Citation:

---

Si ce n'est pas déja le cas ce n'est pas sans raison, je vois difficilement comment adapter un tel fonctionnement en C++. Mais même en admettant que ce soit possible je ne vois pas non plus en quoi ça faciliterait l'émulation d'accesseurs.

---

Pourtant ça s'implémente en bibliothèque et ça marche parfaitement...
C'est juste qu'il faut écrire soit-même les informations de réflexion pour chaque classe concernée, et que ce n'est pas aussi joli que obj.name mais obj.call<'n', 'a', 'm', 'e'>() au mieux.

l'interet de mettre des get/set c'est de pouvoir faire plus que m_index = value;


certains composants "publient" leur interface via un etat (par exemple un booleen)

setState(value) declenche alors un changement d'etat plus consequent, une serie d'operations qui passent l'objet de l'etat A a l'etat B.

mais vu de l'exterieur, l'etat est publie comme un simple enum.



Les classes de donnees regroupant un sensemble de valeurs sont egalement tres pratique; ca s'appelle separer la description et le comportement tout connement. Un programme qui ne contient que du comportement ferait mieux d'etre en C. Un programme contenant du comportement et de la description est en general mieux ecrit en C++. On peut choisir de grouper le comportement et les donnees ou les separer, le comportement travaillant sur des donnees qui lui sont attachees.



Je ne comprend pas bien le proces contre les proprietes, si on est contre les proprietes on est contre la description, on fait un programme qui, lorsqu'il doit etre "tweaké", doit etre recompilé. Ca depend sans doute des domaines d'application mais le fait d'introduire de la description et de la publier d'une mainiere ou d'une autre me parait tres confortable, meme si pas indispensable

screetch, j'ai bien compris que les proprietes permettaient une syntaxe plus legere que des set/get. Mais je conteste l'interet des deux: mes objets ne sont pas des collections d'attributs independants, vision que favorisent les set/get sous n'importe quelle forme syntaxique. Quand j'ai des attributs, ils sont generalement uniquement lisibles, soit qu'ils sont fixes pour la duree de vie de l'objet, soit que les modifications se font par des API qui font plus que ca et dont le nom indique clairement la fonction. Les cas ou j'ai bien des set/get, je les rescend comme des verrues en attente d'etre enlevees ou presentes pour des raisons historiques. Je ne vois pas l'interet d'alleger l'utilisation de verrues.

Comme je crois l'avoir precise, il est possible que ma perception soit liee au domaine dans lequel je travaille ou bien a mon style de conception. Mais pour me faire changer d'avis il me faut des choses plus convaincante que simplement "certains composants "publient" leur interface via un etat".

(Tiens, je viens de remarquer qu'il y a un message de Loic que je n'ai pas lu).

Citation:

---

Envoyé par JolyLoic

J'avoue que l'exemple que j'ai pris n'est pas forcément bien choisi, puisqu'il est vrai qu'en général la position des objets dans une boîte de dialogue dépend d'un gestionnaire de layout. Maintenant, dans une application de type dessin, ou l'utilisateur manipule les coordonnées des objets à la souris, ça peut avoir plus de sens.

Et pour des éléments plus standard d'une IHM, il y a pléthore de choses pour lesquelles une propriété avec ses accesseurs me semble l'abstraction naturelle. Par exemple, pour un bouton, le texte, l'icône, le style d'affichage, les couleurs (soit en RGB, soit en rôle dans une palette de couleurs)... Tous me semblent des chose que l'utilisateur peut vouloir lire ou modifier manuellement, à l'aide d'accesseurs.

J'ai joint une copie d'écran des propriétés exposées d'un bouton dans .NET. Il y en a peut-être quelques unes qui mériteraient un traitement plus global que par une propriété isolée, par exemple le numéro d'ordre pour le bouton tab, mais pour la plupart, cette notion me semble usuelle.
Pièce jointe 18373Pièce jointe 18374

---

Il faudrait que je regarde ca plus en detail. Mais si je connais mal les IHM graphiques, c'est entre autre parce que chaque fois que je veux les regarder d'un peu plus pres, j'ai l'impression d'une complexite sans rapport avec la nature du probleme (en tout cas sans rapport avec la nature des problemes que je cherche a resoudre). Et j'arrive pas a savoir si elle est intrinseque ou si elle resulte d'un mauvais choix d'organisation.

Citation:

---

En fait, en plus de l'IHM, il y a une autre catégorie d'objets pour lesquels la notion de propriété me semblerait une bonne chose, ce sont pour des petits objets, généralement des value types, qui semblent autant se définir par ce qui les compose que par un comportement.

---

Les classes valeurs, j'ai tendance a les faire non mutables, ce qui est incompatible avec la notion de propriete :) std::string est un bon exemple des problemes qui arrivent quand on a une semantique de valeur combinee avec de la mutabilite.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Mais si je connais mal les IHM graphiques, c'est entre autre parce que chaque fois que je veux les regarder d'un peu plus pres, j'ai l'impression d'une complexite sans rapport avec la nature du probleme (en tout cas sans rapport avec la nature des problemes que je cherche a resoudre).

---

Je pense qu'une des raisons est qu'avoir une IHM fonctionelle ne demanderait probablement pas tout ce qui est disponible. Avoir un IHM fonctionelle et faisant plaisir aux graphistes/chefs de projet/responsable marketing demande souvent de régler de manière non usuelle, et manuelle, nombre de petits détails, ce qui oblige donc à une explosion de l'interface pour permettre tous les cas non usuels possibles.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Les classes valeurs, j'ai tendance a les faire non mutables,

---

Je n'ai pas cette habitude. Mais je n'ai jamais particulièrement réfléchi sur le sujet. Je pense que je fais juste comme dans les exemples que j'ai du voir quand j'ai appris la POO, ou comme dans la SL. Tu peux rappeler les avantages ?

Citation:

---

Envoyé par Jean-Marc.Bourguet

ce qui est incompatible avec la notion de propriete :)

---

Du moins pour les propriétés en écriture. Typiquement, quand je code en C# (langage avec des propriétés), je pense qu'à vue de nez, la moitié de mes propriétés au moins ne sont accessibles qu'en lecture.

Citation:

---

Envoyé par Jean-Marc.Bourguet

std::string est un bon exemple des problemes qui arrivent quand on a une semantique de valeur combinee avec de la mutabilite.

---

Des strings non mutables ne sont pas non plus la panacée. Elles ont comme effet, d'après ma faible expérience sur le sujet, de recopier la chaine bien plus souvent qu'il n'est nécessaire. D'où les stringBuilders qui apparaissent dans les langages ayant fait ce choix, ce qui complique un peu l'apprentissage (j'ai entendu parler de gros problèmes de perfs dans des vrais programmes Java résolus par l'utilisation judicieuse de StringBuilder, ce qui prouve que les gens ne les utilisent pas assez).

Tout dépend de quel aspect t'intéresse.
Par exemple, comparer deux std::string est une opération très coûteuse : elle compare individuellement chaque caractère.

Or, avec du partage implicite, il suffit de comparer un pointeur.

C'est pour cette raison, en particulier, qu'utiliser une std::map<std::string, quelquechose> ce n'est pas terrible.

Citation:

---

Envoyé par JolyLoic

Je pense qu'une des raisons est qu'avoir une IHM fonctionelle ne demanderait probablement pas tout ce qui est disponible. Avoir un IHM fonctionelle et faisant plaisir aux graphistes/chefs de projet/responsable marketing demande souvent de régler de manière non usuelle, et manuelle, nombre de petits détails, ce qui oblige donc à une explosion de l'interface pour permettre tous les cas non usuels possibles.

---

Ne serait-il pas preferable de chercher un moyen plus propre (eventuellement dans le langage) de regler cela plutot que d'en mettre la responsabilite a l'exterieur.

Citation:

---

Citation:

---

Envoyé par Jean-Marc.Bourguet

Les classes valeurs, j'ai tendance a les faire non mutables, ce qui est incompatible avec la notion de propriete :) std::string est un bon exemple des problemes qui arrivent quand on a une semantique de valeur combinee avec de la mutabilite.

---

Je n'ai pas cette habitude. Mais je n'ai jamais particulièrement réfléchi sur le sujet. Je pense que je fais juste comme dans les exemples que j'ai du voir quand j'ai appris la POO, ou comme dans la SL. Tu peux rappeler les avantages ?

---

Ca me semble mieux correspondre a la nature des choses. Une valeur est une valeur, on ne la change pas. On change eventuellement une variable contenant une valeur en assignant une autre. (Oui, il peut y avoir un probleme de perf, d'ou le generalement).

Il y a aussi le cas des classes tuples avec tous les membres publics. Mais alors, ce n'est que des simples conteneurs sans avoir d'invariant a maintenir et les proprietes ne conviennent pas (sauf peut-etre pour facilite le refactoring).

Citation:

---

Du moins pour les propriétés en écriture. Typiquement, quand je code en C# (langage avec des propriétés), je pense qu'à vue de nez, la moitié de mes propriétés au moins ne sont accessibles qu'en lecture.

---

Ca ne me generait pas du tout de pouvoir appeler des fonctions sans le () final (j'ai fait assez d'Ada pour etre familier avec cela)... mais je ne suis pas sur que c'est a ajouter au C++ en ne le permettant que dans certains cas et permettre tous les cas est impossible car cela casserait trop de code existant.

(Note qu'une fois qu'on a cela, il suffit d'un proxy pour avoir les proprietes).

Citation:

---

Des strings non mutables ne sont pas non plus la panacée. Elles ont comme effet, d'après ma faible expérience sur le sujet, de recopier la chaine bien plus souvent qu'il n'est nécessaire.

---

Il vaut mieux avoir une implementation qui GC le contenu.

Citation:

---

D'où les stringBuilders qui apparaissent dans les langages ayant fait ce choix, ce qui complique un peu l'apprentissage (j'ai entendu parler de gros problèmes de perfs dans des vrais programmes Java résolus par l'utilisation judicieuse de StringBuilder, ce qui prouve que les gens ne les utilisent pas assez).

---

De mon point de vue, c'est exposer quelque chose qui peut etre fait dans l'implementation d'une classe de string non mutable.

Bonjour, es que quelqu'un pourrai expliquer ce que veut dire "string non mutable" et "string mutable"? je ne comprend pas trop ce que vous voulez dire :cry:
merci

Salut,

Citation:

---

Envoyé par Mongaulois

est-ce que quelqu'un pourrait expliquer ce que veut dire "string non mutable" et "string mutable"?

---

Non-mutable c'est lorsque toutes les méthodes sont 'const' et que pour effectuer une modification tu appelles une méthode qui te renvoit un (en général nouvel) objet modifié mais qui ne modifie pas l'objet initial.
Mutable c'est lorsque tu peux directement modifier l'objet au travers d'une méthode.
Par exemple en C++ les 'strings' sont mutables, en Java elles sont non-mutables.

MAT.

Jean marc, j'ai dit que l'interet des get/set etait de pouvoir faire PLUS (a l'heure actuel) que m_chose = bidule ^^


comme je te l'ai dit, la ou je bosse nous separons le comportement de la description. Si tu ecris du comportement, ca n'a pas de sens d'ecrire des set et peu de sens d'ecrire des get (lire un comportement, say bizarre)

Par contre pour des donnees de description, ca a du sens de les lire et de les changer

nous avons donc 3 gros modules :
- le comportement : le code, pas de get/set
- la description : des get/set, modifier la description change le comportement et le comportement peut changer une description pour modifier un autre comportement, etc
- l'editeur : permet de changer les donnees (offline ou online, c'est a dire alors que le module tourne) et changer le comportement.


Pour etre plus precis le comportement est un jeu, la description est le gameplay (la vie du joueur, les degats de l'armes...) et la personne derriere l'editeur est un designer. Il est bien loin le temps ou les programmers decidaient du gameplay :)


donc voila comment on se sert des get/set, le fait d'avoir des proprietes au lieu des get/set a peu d'importance mais ca reste du sucre syntactique, ca a jamais ete necessaire mais des fois pratique.

Je suis complètement de l'avis de Jean-Marc.
Un mutateur ne me dérange pas spécialement, après tout c'est quand même quelque part une demande de traitement, bien que minimale.
Par contre je suis particulièrement allergique aux accesseurs qui vont à mon sens à l'encontre de l'élégance et de la simplicité d'un design orienté objet.
Dans la grande majorité des cas les accesseurs n'ont pas lieu d'être et ils participent surtout à la vision procédurale du code :
"oh tiens j'ai besoin de telles données pour effectuer le traitement que je suis en train d'écrire => get get à droite get get à gauche et voilà !"
C'est pas tant le fait d'éclater l'encapsulation qui me dérange que celui d'inverser le flux d'exécution :
si A utilise un accesseur dans B on va se dire que A manipule B alors que c'est quelque part l'inverse puisqu'en fait B envoie des données vers A.
Quand on commence à alterner les appels de demande de traitement et les appels à des accesseurs c'est là que le code devient spaghetti et qu'il perd son bel ordonnancement linéaire du flux d'exécution des entrées jusqu'aux sorties.

Je partage tout à fait ce sentiment d'échec d'avoir à mettre un accesseur à un endroit, je suis reste persuadé qu'on peut faire mieux.
Après que ça soit ajouté ou non dans le language ça m'est un peu égal, de toute façon il y a déjà une sur-utilisation systématique et je ne pense pas que ça change grand chose...

MAT.

Une petite remarque sur les strings java: il y a plusieurs raisons non citées pour lesquelles il sont non mutables.
Tout d'abord, le java ne permet pas la const-correction. Donc, si String était mutable et qu'on concevait une classe avec un... accesseur en lecture seule, rien n'empecherait de modifier le string (illogique, vu qu'en lecture seule).
Ensuite, il y a aussi une certaine utilité pour l'optimisation si on sait bien s'en servir, nottament pour les comparaisons. En java, tous les objets sont sensés proposer la méthode hashcode, qui renvoie un crc32 des parties identifiantes de l'objet. Pour les strings, le calcul de ce crc se fait à la création du string. Donc, lors d'une comparaison case sensitive on commence par comparer les réfèrences, puis on passe au hashcode et ensuite seulement à une vérification caractère par caractère. C'est aussi très utile pour la création de Map (classement par crc dans un arbre binaire). Si String était mutable, ce serait impossible.
En combinant de manière optimale String et StringBuilder, on obtient des complexités algorithmique pour le traitement des chaines de caractères meilleures qu'avec std::string.

En dehors de ça, pour Jean-Marc: ok, on a compris que tu n'as pas besoin d'accesseurs parceque tu ne crées jamais d'objets qui sont une collection d'attributs, alors j'ai deux questions:
- Comment tu fais?
- Même si ta technique de conception OO est super au point, tu ne me feras pas avaler que le bon vieux exemple d'une classe voiture avec attributs couleur, longueur, ect... est objectivement mauvais et bon à jeter. Même si tu ne le fais jamais d'autres le font et peuvent tout de même être de très bon programmeurs, et pour eux les accesseurs sont utiles. Personnellement je connais le pl/sql, je le hais profondément, mais je ne vais pas prétendre pour autant que ça n'a de place dans aucune équipe de développement.

Citation:

---

Envoyé par zais_ethael

En dehors de ça, pour Jean-Marc: ok, on a compris que tu n'as pas besoin d'accesseurs parceque tu ne crées jamais d'objets qui sont une collection d'attributs,

---

J'ai des classes qui sont une collection d'attributs. Les membres sont alors tous publics et je n'ai que faire d'ajouter du comportement.

J'ai aussi des setter/getter, mais comme je l'ai signale plus haut, la plupart je les ressens comme des verrues soit en attente de refactorisation, soit a conserver pour des raisons historiques. Je ne suis pas parfait ni ne travaille pas dans un environnement ideal. J'essaie simplement d'etre pragmatique et de favoriser les pratiques que je considere comme saines. J'essaie aussi de m'instruire, en cherchant a comprendre pourquoi certains veulent favoriser des conceptions qui me semblent batardes; ce n'est pas impossibles de me faire changer d'avis -- il suffit d'avoir des arguments convainquants.

Citation:

---

- Comment tu fais?

---

Donne moi un exemple qui ressemble a quelque chose et j'y reflechirai. Loic est en train de me convaincre qu'il y a un probleme dans le cas des IHM. Pour le moment je cherche a le comprendre a mes rares moments perdus. J'en suis a me demande si une solution plus propre ne serait pas autre chose. Peut-etre un moyen plus leger de creer des classes derivees (eventuellement meme non nommee).

Citation:

---

- Même si ta technique de conception OO est super au point,

---

Je n'en sais rien. Je suis certainement plus un specialiste de mon domaine qu'un specialiste de la POO. Je manque d'experience dans d'autres domaines que le mien, c'est certain. Et je ne considere pas la POO comme une panacee universelle -- voir mes messages sur le sujet par ailleurs.

Citation:

---

tu ne me feras pas avaler que le bon vieux exemple d'une classe voiture avec attributs couleur, longueur, ect... est objectivement mauvais et bon à jeter.

---

Donne moi un probleme reel. C'est le genre d'exemples utilises pour exposer la POO qui me semblent plus nuisibles que profitables parce qu'ils sont tellement simplifies qu'ils forcent des solutions denaturees qu'on enseigne comme exemples a suivre.

Citation:

---

Même si tu ne le fais jamais d'autres le font et peuvent tout de même être de très bon programmeurs, et pour eux les accesseurs sont utiles.

---

Est-ce qu'il y a en a tant que cela qui sont convaincus que le C++ serait mieux avec que sans? J'ai trouve trois papiers du commite. Par ordre du plus recent au plus vieux.

- David VdV en entete d'un document presentant les properties de C++/CLI: "This document is neither a proposal to include this extension in standard C++, nor an endorsement of this extension by the author"

- Lois Goldthwaite a bien ecrit "C++ Properties -- a Library Solution", mais en lisant les deux premieres pages, on a l'impression d'un requisitoire contre la notion en C++ "I can't help feeling that is an effort to impose an alien idiom in C++", "I think this is A Bad Idea", "summary of a member having about a decade of experience with property: properties made our code easier to write, but immensely more difficult to maintain", "other member experience: very elegant and usable in Delphi, rather less in C++" -- etre aussi peu convaincue de l'interet de qqch qu'on presente est extraordinaire.

- le plus positif est le plus vieux: Borland (pas d'auteur individuel) presentant les extensions de leur compilateur.

les papiers sur les proprietes parlent elles däajouter des extensions qui permettent de les interroger en runtime par leur nom ? de fournir un vrai RTTI avec introspection ?
ou juste une methode de feignasse qui veut pas ecrire les parentheses ?

Citation:

---

Envoyé par screetch

les papiers sur les proprietes parlent elles däajouter des extensions qui permettent de les interroger en runtime par leur nom ? de fournir un vrai RTTI avec introspection ?

---

Je n'ai pas vu de proposition d'introspection (et il n'y a pas réellement de propositions pour ajouter des propriétés).

À mon avis la seule manière de faire ça proprement c'est de travailler avec des chaînes de caractères "compile-time".

Par exemple, on pourrait surcharger l'opérateur . ainsi :

objet.foo

appellerait en fait objet.operator.<boost::mpl::vector_c<char, 'f', 'o', 'o'> >();

objet.foo2(arg1, arg2)

appellerait en fait objet.operator.<boost::mpl::vector_c<char, 'f', 'o', 'o', '2'> >(arg1, arg2);

Ensuite, pour pouvoir bien exploiter ça (en particulier pour pouvoir directement appeler les réelles fonctions), il faudrait des outils d'introspection à la compilation qui permettent à partir du nom d'un membre de l'appeler, par exemple.