Discussion :

[Astraya]

Bonjour à tous,

Je viens demander un renseignement sur qui dit vrai dans mon histoire

Dans le code suivant : https://godbolt.org/z/nv31E444d

GCC et Clang sont OK
MSVC n'est pas OK car il cherche un constructeur par copie... Ce qui ne devrait pas être le cas selon moi.
Mais dans le doute, je demande au sénior leur avis

Merci

[koala01]

Salut,

En fait, je dirais que c'est MSVC qui se plante dans la détection automatique des paramètres template.

A sa décharge, le fait que ta fonction move_or_copy_construct nécessite deux paramètres template ne facilite sans doute pas les choses, car, pour autant que l'on sache, on std::is_constructible_v<T, U&&> peut matcher sur deux situation bien distinctes:

• Soit T et U correspondent à un même type, et nous avons donc affaire à un constructeur de copie par déplacement "normal" (ex MaClasse(MaClasse &&))
• Soit T et U correspondent à un type différent, et nous avons donc affaire à un constructeur paramétré "classique" qui va tenter de déplacer le paramètre qui lui est donné (ex: MaClasse(UnAutreType &&))

Cependant, il s'agit d'un problème assez récurrent avec MSVC, dans le sens où, normalement, le code qui ne "matche" pas un expression template est sensé ne purement et simplement pas être compilé alors que MSVC s'obstine à compiler tout le code qu'il trouve, ce qui, dans le cas présent, l'amène à tenter une copie alors qu'il aurait du se contenter d'une copie par déplacement .

Et je ne suis même pas sur que le fait de clairement séparer le processus de copie du processus de copie par déplacement ait la moindre chance de résoudre quoi que ce soit :'(

Je crains donc que le seul moyen de satisfaire MSVC serait de fournir un constructeur de copie "classique" (éventuellement protégé par un test préprocesseur #if defined(WIN32) ou similaire), et d'avoir confiance dans le fait que le test s'assurant qu'une copie par déplacement soit effectué en premier garantisse l'utilisation préférentielle de celui-ci par rapport au constructeur de copie "classique".

Ceci étant dit, dans le sens où le constructeur de copie par déplacement de F ne fait en réalité rien d'autre que ce que le compilateur pourrait fournir comme implémentation par défaut pour ce genre de fonction, tu pourrait tout aussi bien remplacer l'implémentation par un = default qui te faciliterait la tâche

[Astraya]

Oui je suis d'accord avec toi.
Il s'agit pour moi d'un bug du compilateur car le comportement est correcte dans un contexte non constant ( Le constructeur par déplacement est correctement appelé ).
Je n'ai trouvé aucun workaround appart ajouter ce constructeur par copie mais cela n'est une solution viable que si le constructeur par copie et le constructeur par mouvement ont le même "comportement/code" vie à vie de la construction.
Je ne peut pas obliger les développeurs a fournir un constructeur par copie pour dans une expression constante uniquement.

J'ai ouvert un ticket https://developercommunity.visualstu...-works/1545985

On va bien voir.

Merci encore

[Astraya]

Bonne nouvelle,

La fonction std::construct_at sera fixé dans la prochaine release de Visual Studio.
Lien de l'issue: https://developercommunity.visualstudio.com/t/constexpr-std::construct_at-do-not-works/1545985