Discussion :

[JolyLoic]

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.

[Alp]

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 :

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

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

Ou bien

Code :

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

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

[befalimpertinent]

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

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 ?

[loufoque]

Moi j'aurais bien vu

Code :

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

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

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

[Alp]

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.

[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 et de me les palucher tous un par un c'est une peu barbant...

[loufoque]

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

C'est-à-dire ?

[baptistoux]

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

Code :

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

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é

[JolyLoic]

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.

[Mat.M]

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é

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 )

[Mat.M]

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

[zais_ethael]

?
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

[Jean-Marc.Bourguet]

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

C'est du sucre syntaxique. Et on sait que

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?

[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 ?

Code :

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

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.

[Jean-Marc.Bourguet]

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 :

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

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)

[Luc Hermitte]

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 et de me les palucher tous un par un c'est une peu barbant...

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


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.

[loufoque]

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

[Jean-Marc.Bourguet]

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.

[zais_ethael]

L'interet, comme le cite si bien 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.

[Jean-Marc.Bourguet]

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.