Discussion :

[koala01]

On parle beaucoup de langage, mais peu de développement.
Il y a eu une petite tentative hier, qui consistait à mettre les choses sur la table (je parle de copies d'écran par exemple) le suggestion n'a pas été relevée.

Par ailleurs, un objet est un ensemble d'éléments divers groupés sous une seule identité, une classe. Si cette affirmation est juste, je voudrais bien qu'on m'explique comment on peut comparer deux objets. Soit ils sont identiques, et donc il y en a un de trop, soit ils des caractères communs, ou semblables ou pareils,

Soit, enfin, ils ont deux origines distinctes, et il est intéressant de pouvoir déterminer qu'ils représentent une valeur commune.


alors on pourra écrire des fonctions comme

Code :

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

1
2
3
4
5
6
7
8
9
class Quelconque
{
  ...
  float Longueur();
  float Aire();
  bool IsMemeLongueur(Quelconque &c); 
  bool IsMemeAire(Quelconque &c);
};

Mais que pourrait-il y avoir dans un code de surcharge de l'opérateur == ?
Remarque : ceci n'est pas un exemple comme dans ma précédente question.
Il s'agit tout de même de la même question, mais pas la peine de répondre sur l'exemple.

Et je vais pourtant y répondre:

Si l'on peut estimer que deux objets quelconques sont considérés comme identique à partir du moment où ils ont:

1. la même position d'origine (celle à partir de laquelle sont déterminées les autres cotés)
2. la même surface
3. la même longueur
4. peut être d'autres proriétés comparables, comme le nombre d'angles

tu saura déterminer la logique à suivre pour ton opérateur ==

Si l'une de ces données est inutile, supprime la, tout simplement

Si tu considère que deux objets ne peuvent être identiques que s'ils se réfèrent à une même instance, compare les adresses auxquelles ils se trouvent.

l'opérateur == est un opérateur de comparaison permettant de déterminer l'égalité éventuelle entre deux opérandes.

A partir de là, libre à toi d'estimer, dans le cadre de ton projet, si une équivalence peut ou non être considérée comme égalité, et, dans le cas d'objets disposant d'équivalences composables (une surface identique, mais pas forcément la même longueur, ou vice versa), quelles équivalences permettront d'assurer l'égalité lors de la comparaison.

[Florian Goo]

Si tu considère que deux objets ne peuvent être identiques que s'ils se réfèrent à une même instance, compare les adresses auxquelles ils se trouvent.

Dans ce cas-là (qui porte un nom : sémantique d'entité), il est préconisé de ne pas surcharger l'opérateur d'égalité du tout.
Cf notre eeeexcellente FAQ http://cpp.developpez.com/faq/cpp/in...s#CLASS_entite .

[koala01]

La bonne pratique dans ce cas-là (qui porte un nom : sémantique d'entité), il est préconisé de ne pas surcharger l'opérateur d'égalité du tout.
Cf notre eeeexcellente FAQ http://cpp.developpez.com/faq/cpp/in...s#CLASS_entite .

héhé... aussi...

Et comme on travaillera souvent avec des pointeurs ...

[Invité]

Oui, "pointeurs intelligent" ... moi, je préfère me réserver le côté intelligence dans l'application, et laisser au langage le soin de traduire en code exécutable ce que j'écris en code lisible par moi et d'autres.
Quelque soit le nom du langage, je travaille avec ce que j'ai, et je m'en contente PAR DEFINITION.
Quand je lis "ce sera dans la prochaine version", je ne dis que j'ai bien raison de me contenter de ce que j'ai. Mon but n'est pas d'utiliser un langage mais de développer. Je comprend ceux qui cherchent à écrire ou améliorer un langage, il en faut, mais je ne pense pas que ce soient les mêmes qui sont le mieux placés pour dire aux développeurs comment ils doivent faire.

Concernant la surcharge des opérateurs pour les classes. Il y a bien longtemps que j'ai compris que ce n'était pas vraiment utilisable pour des objets, il ne peut y avoir qu'une seule surcharge du signe == et des quantités de choses susceptibles d'être comparées. Donc, sauf cas très particuliers, je considère que c'est un gadget très satisfaisant pour l'esprit, mais pas vraiment utilisable.

[Florian Goo]

Oui, "pointeurs intelligent" ... moi, je préfère me réserver le côté intelligence dans l'application, et laisser au langage le soin de traduire en code exécutable ce que j'écris en code lisible par moi et d'autres.

Je trouve moi aussi que le terme « intelligent » est plutôt malheureux, d'autant plus que, contrairement à un GC, ils font en sorte de maintenir le développeur concerné par la gestion de la mémoire : leur usage est explicite et il existe plusieurs types de pointeurs intelligents dont chacun est adapté à une situation.

Quand je lis "ce sera dans la prochaine version", je ne dis que j'ai bien raison de me contenter de ce que j'ai. Mon but n'est pas d'utiliser un langage mais de développer. Je comprend ceux qui cherchent à écrire ou améliorer un langage, il en faut, mais je ne pense pas que ce soient les mêmes qui sont le mieux placés pour dire aux développeurs comment ils doivent faire.

La notion de pointeur intelligent existe dans la STL depuis le début (std::auto_ptr, dont l'usage est certes déconseillé, mais il existe). Il y a aussi (et surtout) ceux de Boost (en particulier shared_ptr).
Je ne sais pas si la dernière phrase de la citation m'est destinée, mais je prends le C++ et les pointeurs intelligents pour ce qu'ils sont : des outils.

Concernant la surcharge des opérateurs pour les classes. Il y a bien longtemps que j'ai compris que ce n'était pas vraiment utilisable pour des objets, il ne peut y avoir qu'une seule surcharge du signe == et des quantités de choses susceptibles d'être comparées. Donc, sauf cas très particuliers, je considère que c'est un gadget très satisfaisant pour l'esprit, mais pas vraiment utilisable.

Nous sommes d'accord qu'il faut utiliser la surcharge d'opérateur avec sagesse. De là à dire que ce n'est pas utilisable…
Je suis bien heureux de pouvoir écrire « if(string1 == string2) ». Je suis également bien heureux que les conteneurs de la STL me garantissent un traitement optimal de mes objets en l'échange de la surcharge des opérateurs de comparaison.

[koala01]

Quand je lis "ce sera dans la prochaine version", je ne dis que j'ai bien raison de me contenter de ce que j'ai. Mon but n'est pas d'utiliser un langage mais de développer. Je comprend ceux qui cherchent à écrire ou améliorer un langage, il en faut, mais je ne pense pas que ce soient les mêmes qui sont le mieux placés pour dire aux développeurs comment ils doivent faire.

Pour autant que je sache, une bonne part de ceux qui participent à l'élaboration de la nouvelle norme sont eux-même des développeurs reconnus qui ont retourné le langage dans tous les sens (l'un n'empêche pas l'autre hein )

Pour le reste des développeurs, ceux du "commun des mortels" qui ne font qu'utiliser le langage, il est possible de considérer C++ comme le "moins mauvais langage" (à défaut de le considérer comme le meilleur ) et donc d'être tout à fait conscient de certains problèmes qui, justement, seront (peut-être!!) résolus dans la nouvelle mouture.

Ceux-là sont donc parfaitement en droit d'attendre cette nouvelle mouture avec impatience

Concernant la surcharge des opérateurs pour les classes. Il y a bien longtemps que j'ai compris que ce n'était pas vraiment utilisable pour des objets, il ne peut y avoir qu'une seule surcharge du signe == et des quantités de choses susceptibles d'être comparées. Donc, sauf cas très particuliers, je considère que c'est un gadget très satisfaisant pour l'esprit, mais pas vraiment utilisable.

C'est là que la notion de sémantique de valeur ou d'entité intervient.

Certaines choses peuvent ou doivent être comparables afin, par exemple, d'en permettre un tri:

Une chaine de caractères, par exemple, doit l'être afin de permettre de placer Alphonse Baudais avant William Sheakespear (j'hésite sur l'orthographe des deux )si le besoin s'en fait sentir.

Il en va de même pour les vecteurs ou les matrices(au sens mathématique du terme), par exemple.

Et, de manière générale, on peut souhaiter savoir si le contenu d'une collection d'objets correspond au contenu d'une autre, ou si un objet d'un type particulier peut être considéré comme identique à un autre (à charge pour le développeur de déterminer ce qui rend les deux objets identiques) parce que les deux ont des origines différentes.

Ces comparaisons peuvent être effectuées avec des fonctions membres, mais on perd la possibilité d'un éventuelle réflexibilité que l'on pourrait être en droit d'attendre de la part de certains types d'objets.

[Floréal]

Je trouve moi aussi que le terme « intelligent » est plutôt malheureux, d'autant plus que, contrairement à un GC, ils font en sorte de maintenir le développeur concerné par la gestion de la mémoire : leur usage est explicite et il existe plusieurs types de pointeurs intelligents dont chacun est adapté à une situation.

Il me semble que c'est une question de point de vue encore ici: Soit on veut un programme où tout est sous contrôle, même la gestion mémoire, soit on délègue ça à une machine virtuelle ou à des paramètre que l'on aura laissé à l'intérieur de notre code source en fonction du langage utilisé. En d'autre terme soit on se fait confiance - à soi-même ou à nos développeurs -, soit on fait confiance en les algorithmes - qui peuvent tout à fait convenir! - sur lesquels on a ou pas la forcément main.
Après il existe des bonnes pratiques dans certains langages qui n'ont aucun sens dans d'autre comme le RAII en C++, inapplicable en Java. Ce n'est qu'une question (mal placée, à mon sens) d'affinité avec une plateforme ou un langage.

[_skip]

Pour la défense de la surcharge d'opérateur, je me permet de citer ce cas en java :

Code :

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

1
2
3
BigDecimal price = new BigDecimal(250);
BigDecimal tax = price.multiply( new BigDecimal(19.6) ).divide( new BigDecimal(119.6)) ;

Un code équivalent utilisant la surcharge d'opérateur (possible en c++) serait quelque chose comme :

Code :

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

1
2
3
BigDecimal price(250);
BigDecimal tax = price * 19.6 / 119.6 ;

Sans rire, c'est nettement plus lisible?

[Klaim]

En fait, ça dépends : moi personellement en C++ j'aurais mis un constructeur explicit à un type BigDecimal , de manière à avoir plutot :

Code :

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

BigDecimal tax = price * BigDecimal(19.6) / BigDecimal(119.6) ;

C'est plus lisible que Java sans être aussi peu explicit (concernant les types impliqués) que ton exemple de C++.

Cela dit, une meilleure solution existera (et oui dans C++0x/1x, donc pas tout de suite, mais au moins elle est prévue) : les suffix custom (par exemple ici BD pour BigDecimal) :

BigDecimal tax = price * 19.6BD / 119.6BD ;

Ca résoudra ce genre de probleme de syntaxe lourde a cause des casts implicites.

[pseudocode]

Pour la défense de la surcharge d'opérateur, je me permet de citer ce cas en java :

Code :

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

1
2
3
BigDecimal price = new BigDecimal(250);
BigDecimal tax = price.multiply( new BigDecimal(19.6) ).divide( new BigDecimal(119.6)) ;

Un code équivalent utilisant la surcharge d'opérateur (possible en c++) serait quelque chose comme :

Code :

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

1
2
3
BigDecimal price(250);
BigDecimal tax = price * 19.6 / 119.6 ;

Sans rire, c'est nettement plus lisible?

Oui, c'est clair que c'est nettement plus lisible... Ces classes sont vraiment une plaie à utiliser en Java.

D'un autre coté, la sémantique de ces opérateurs est assez évidente dans le contexte de l'arithmétique. C'est nettement mois évident si tu remplaces "BigDecimal" par "Triangle" ou "Dog".

[Invité]

BigDecimal tax = price * 19.6BD / 119.6BD ;

Ca, ça me rappelle le BasicA
Mais si j'avais à faire une classe type BigDecimal, où le membre le plus important est le prix, je ferais quelque-chose comme ça:

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 BigDecimal
{
private:
  long double PrixHT;
  int nombreU;
  int Societe;
  float LesTVA[10];
  float LesPourcentBenef[8];  
public:
  BigDecimal(float PuHT,int U, ...);
  long double PrixTTC(...);
  long double Benef(...);
...
};

Et ... pas de surcharge d'opérateur, puisque P1 = new BigDecimal(...) et P2 = new BegDecimal(...) ne sont plus comparables.

[Davidbrcz]

D'un autre coté, la sémantique de ces opérateurs est assez évidente dans le contexte de l'arithmétique. C'est nettement mois évident si tu remplaces "BigDecimal" par "Triangle" ou "Dog"

D'ou les notions de classe a semantique de valeur et de celles a semantique d'entite ... On revient a la meme chose : Le C++ donne un outil, c'est pas la faute du langage si des idiots font nimporte quoi avec ....

Pierre Dolez >> Dune classe BigDecimal, a la vue de son nom, j'attends qu'elle represente d'une maniere speciale un nombre. Or la, il y a un dephasage entre le nom de ta classe et son role.

[_skip]

D'un autre coté, la sémantique de ces opérateurs est assez évidente dans le contexte de l'arithmétique. C'est nettement mois évident si tu remplaces "BigDecimal" par "Triangle" ou "Dog".

Tu as raison, mais personnellement je ne suis pas trop d'accord avec le principe qu'il faut bannir des fonctionnalités sous prétexte qu'on peut faire des choses bizarres avec. Je préfère un langage riche dont j'utilise 50% à un langage pauvre dont j'aurai besoin de 110% .

Je dirai que la redéfinition d'opérateur devrait le plus souvent se borner aux cas où la sémantique est justement comme tu le dis: évidente, ou tout au moins cohérente.

Cependant, j'ai aussi vu dans un mappeur objet-relationnel en C# une approche intéressante pour construire des filtres qui utilisait une syntaxe de ce genre :

Code :

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

1
2
3
4
5
6
//filtrer toutes les factures terminées de plus de 100E faites par le client Dupont 
Filter filter = new Filter();
filter.addCondition( OrderFields.Price > 100.0  );
filter.addCondition( OrderFields.Status == "commited");
filter.addCondition( OrderFields.Customer == "Dupont");

La signature de la méthode était

Code :

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

void addCondition(IPredicate);

Ceci était rendu possible par le fait que la classe des objets Price, Status, Customer avait ses opérateurs <, >, ==, != redéfinis de telle façon à retourner un objet implémentant l'interface IPredicate.

C'était très commode à utiliser et très lisible, même si ça cassait la sémantique réelle des opérateurs, cependant les objets Fields ne servaient qu'à cela et l'utilisateur du code ne créait pas d'instance.

[jblecanard]

C'est aussi super pratique dans boost::program_options. Certes, cela peut perturber le novice, mais ça nous fait économiser tellement de code en général...

[bacelar]

Les C++istes qui critiquent Java mais qui ne connaissent pas l'autoboxing.
http://lroux.developpez.com/article/..._2#Lautoboxing
Et ça fait plus de 10 ans que je n'ai pas fait une ligne de Java.

Pour la syntaxe des prédicats en C#, c'est encore plus lisible avec LINQ.
Mais il ne faut pas trop essayer de se mettre à la place du compilateur, sinon c'est l'entorse de cerveau assurée. (comme les templates )

Avant de critiquer les autres langages, commencez à les connaître pour voir ce qui y est intéressant.

[pseudocode]

D'ou les notions de classe a semantique de valeur et de celles a semantique d'entite ... On revient a la meme chose : Le C++ donne un outil, c'est pas la faute du langage si des idiots font nimporte quoi avec ....

Dans ce cas particulier, c'est plus la notion de lisibilité du code qui me plait.

La notion de sémantique valeur/entité ca me semble plus être une tentative de rationaliser une situation ambigüe dans le langage : "est-ce qu'on parle du contenu (valeur) ou du contenant (entité)". Situation ambigüe qui (a mon sens) existe à cause de la cohabitation pointeur/référence dans le C++

[Florian Goo]

Les C++istes qui critiquent Java mais qui ne connaissent pas l'autoboxing.
http://lroux.developpez.com/article/..._2#Lautoboxing
Et ça fait plus de 10 ans que je n'ai pas fait une ligne de Java.
C++iste est-il synonyme d'autiste ? Ou de jésuite de très mauvaise foi ?

C'est différent.
Cela ne fonctionne qu'avec les types primitifs. En C++, on peut surcharger les opérations de cast quel que soit le type.

[_skip]

Quelqu'un peut m'expliquer où il est question d'autoboxing dans les derniers posts?

[Florian Goo]

Situation ambigüe qui (a mon sens) existe à cause de la cohabitation pointeur/référence dans le C++

Pourquoi ça ?

Il me semble que c'est un aspect de conception et non de langage. En C++, on se demandera « ma classe doit-elle surcharger == ? » et en Java « ma classe doit-elle redéfinir equals() ? ».

[Florian Goo]

Quelqu'un peut m'expliquer où il est question d'autoboxing dans les derniers posts?

L'exemple avec BigDecimal, je pense.
Mais il y a effectivement confusion, vu que BigDecimal n'est ni un type built-in du C++, ni un type de la lib standard.