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