Le compilateur implémente déja un certain nombre de choses par défaut, ça ne semble pas évident qu'un constructeur de copie soit moins trivial ou plus important que de s'assurer que l'opérateur != renvoie NOT(==).
Continuellement inventer des cas particulier au compilateur c'est ce qui rend déjà le C++ imbitable. Comme je disais plus haut quitte à ajouter une usine à gaz autant permettre à une méthode d'être dè-virtualisée en l'inlinant dans la classe fille. C'est plus générique et ce sera l'occasion d'ajouter une nouvelle syntaxe abscons au langage.
L'autre raison, c'est peut-être que s'il faut se taper la doc de boost et une dépendance supplémentaire, autant se taper l'implémentation de l'opérateur manquant.
Demander l'ajout de cette classe dans la bibliothèque standard c'est pas plus simple ?
Demander au compilateur d'avoir du sucre syntaxique pour des cas particuliers ne me semble pas une bonne idée (surtout quand il est possible de faire autrement).
[^] # Re: Namespace bits ?
Posté par barmic . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 2.
Continuellement inventer des cas particulier au compilateur c'est ce qui rend déjà le C++ imbitable. Comme je disais plus haut quitte à ajouter une usine à gaz autant permettre à une méthode d'être dè-virtualisée en l'inlinant dans la classe fille. C'est plus générique et ce sera l'occasion d'ajouter une nouvelle syntaxe abscons au langage.
Demander l'ajout de cette classe dans la bibliothèque standard c'est pas plus simple ?
Demander au compilateur d'avoir du sucre syntaxique pour des cas particuliers ne me semble pas une bonne idée (surtout quand il est possible de faire autrement).