Reprise du message précédent :

 
En effet, les deux sont vrais. La subtilité vient du fait que j'ai précisé "si on est sûr que le comportement implicite est ce que l'on désire". Et c'est souvent là que le bât blesse.
En effet, j'imagine que des gens qui ne connaissent pas la déclaration du constructeur de recopie n'ont qu'une idée assez vague de son comportement implicite. Et évidemment, dès qu'ils ont une classe nécessitant une implémentation particulière, ils ne le font pas et ça provoque des bugs.
 
Par contre, j'utilise tous les jours sans m'en préoccuper plus que ça les conversions implicites de int en long (long mylong = 0;) et je ne me souviens pas avoir un jour eu un problème.
 
edit: couleurs, interversion de long et de int

Honnètement, je pense que le constructeur de recopie est le moins indispensable de tous les éléments de la forme de Coplien.
 
Dans quel cas a t'on besoin d'un constructeur de recopie ? Dans le cas ou on passe des objets par valeur. Et sincèrement, j'ai toujours réussi à éviter de passer des objets par valeur. Il y a mille et une manières d'éviter de passer des objets par valeur.

Et dans les cas ou tu construit un objet par recopie ?
 

 
Ca ne t'arrive jamais ça un de ces 2 cas ?

Je crois profondément que les cas tordus sont les plus rares. La plupart du temps, les programmeurs ont besoin de faire des choses standard.
Il n'est évidemment pas question de rendre impossible le code tordu ; je me demande simplement pourquoi, dans un langage aussi courant, il est plus facile d'écrire des choses tordues que d'écrire des choses standard. Ce devrait être le contraire. Ainsi, le programmeur, naturellement, programmerait rigoureusement, et, quand il veut faire un truc tordu, il en a la possibilité -- mais ça lui coûte, par exemple en nombre de lignes de code ; d'une certain manière, le fait même qu'il s'est pris la peine d'écrire du code tordu alors même que c'était plus pénible pour lui, justifie la nécessité de ce code tordu. Et ainsi, le type qui relit le code derrière, il peut voir aussi tout de suite qu'il a affaire à du code délicat.

Autre exemple : il serait beaucoup plus sûr de faire en sorte que les objets soient naturellement passés par référence. Bien sûr, on peut toujours avoir besoin de passer des données par valeur, mais il faudrait un mécanisme explicite de passage par valeur (par exemple, certains Basic ont un mot-clé ByVal qui annonce clairement "passage par valeur" ). Et le compilateur, au passage pourrait imposer la présence d'un constructeur par recopie pour la classe en question (vérification qu'aujourd'hui, à ma connaissance, il ne fait pas, même s'il invoque ce constructeur dans le code qu'il génère).

 
Va voir Eiffel, tu as la possibilité de déclarer certains champs de ta class 'expanded' et non par référence, comportement par défaut.
Mais c'est typiquement de truc où tu rentres dans une galère sans nom (comme en C++, des truc deviennent interdits etc.), par défaut le comportement est d'aggréger par référence.

Pour moi, le moins indispensable est le constructeur par défaut.
Le C++ permetra tôt ou tard de spécifier les paramètres des éléments d'un new[].
 
Si les trois autres sont appelés "the big three", c'est parce qu'il est rarissime d'avoir besoin de l'un sans les deux autres.
 
 

Presque par définition, dirais-je.
Le truc inhabituel peut être essentiel, crucial à un projet.
C'est pour ça qu'il doit rester possible, et c'est aussi l'avis de Bjarne Stroustrup.
 
 

Tout à fait d'accord, et pas qu'un peu !
Mais 2 problèmes:

• Il n'est pas toujours facile de déterminer ce qu'est 'la chose standard', et celle-ci peut changer avec la mode ou l'évolution des techniques.
• Concrètement, comment on fait ?

2 idées:
1) Pouvoir spécifier (en tête de source) des options d'implicite, du genre "Option Explicit" de VB.

Inconvénients:
-Le sens du source est très différent suivant le contexte.
-À trop configurer, chacun créé son propre dialecte du langage.
 
2) Pouvoir nier ou la commander une spécification automatique.

Un tel système risque de tourner à l'usine à gaz, et je doute fort qu'il puisse être cohérent et évolutif.
 
 
Mince, ça aurait plus sa place dans [Topic unique] débats sur les langages