Discussion :

[David Fleury]

Bonjour,
gcc 3.4.5 me refuse ça

Code :

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

1
2
3
4
5
6
7
 
class A {  A( const A& );
public:
  A() {}
};
void foo ( const A& a ) {}
int main() {   foo( A() ); }

temp_unamed.cpp: In function `int main()':
temp_unamed.cpp:2: error: `A::A(const A&)' is private
temp_unamed.cpp:12: error: within this context

VS2003 et VS2005 ne disent rien et j'ai pas de gcc 4 sous la main.

qui à tort ou raison ?
Merci

[lun4t1k]

C'est privé par défaut si l'on ne le spécifie pas?
Pourquoi ne pas écrire ton const/copie ds la partie public (ou privée)?
Si c'est une rvalue que tu cherches à créer, je ne sais pas si ca s'adapte pour les fonctions ou méthodes...

Je ne vois pas trop l'intéret comme ca, ca t'appelle le constructeur par def de A puis foo...

[Charlemagne]

Oui, les fonctions membres sont privées par défaut dans une classe.
Par contre, elles sont publiques par défaut dans une structure. (je crois bien d'ailleurs que c'est la seule différence avec une classe)

[lun4t1k]

Ok merci :p

[loufoque]

qui à tort ou raison ?

GCC.
Le standard dit que quand on passe un temporaire par référence celui-ci doit être copiable.

Comeau est plus clair :

Code :

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

1
2
3
4
5
6
ComeauTest.c(7): error: "A(const A &)" (declared at line 2), required for copy that
  was eliminated, is inaccessible
  int main() {   foo( A() ); }
                      ^
 
1 error detected in the compilation of "ComeauTest.c".

[lun4t1k]

kézako commeau?

[David Fleury]

GCC.
Le standard dit que quand on passe un temporaire par référence celui-ci doit être copiable.

Comeau est plus clair :

ah oui, j'ai pas pensé à comeau pour tester.
Merci.


Bon dommage, pour moi en tout cas, je ferais sans.

[Laurent Gomila]

kézako commeau?

Un compilateur C++ qui est connu pour respecter relativement bien le standard.
Je crois même me souvenir que tu peux compiler des bouts de code en ligne.

[lun4t1k]

Apparement il n'est pas compatible avec visual studio 8
dommage...

[Laurent Gomila]

Apparement il n'est pas compatible avec visual studio 8
dommage...

Qu'est-ce qui n'est pas compatible ?

[lun4t1k]

compilable on va dire

[Charlemagne]

Le standard dit que quand on passe un temporaire par référence celui-ci doit être copiable.

Je connaissais pas cette règle. Pour quelle raison une telle restriction, puisque y'a pas de copie à faire?
(Ceci dit je suis jamais tombé sur ce problème puisque c'est pas courant de déclarer les constructeurs de copie comme étant privé)

[Jean-Marc.Bourguet]

Je connaissais pas cette règle. Pour quelle raison une telle restriction, puisque y'a pas de copie à faire?

Un appel explicite au constructeur est une rvalue. Tout comme les résultats de fonctions qui ne retournent pas des références ou les littéraux et d'un certain nombre d'opérateurs.

Quand on passe une rvalue à une référence (qui doit être nécessairement constante), il faut introduire un temporaire qui est un nouvel objet non nommé (par exemple pour contenir le résultat de l'opération 1+3 que l'on passe à un int const&).

Pour créer le nouvel objet, il faut appeler son constructeur de copie soit visible (oui, le constructeur de copie qui prend généralement un A const& est traité particulièrement).

Une création de temporaire par l'appel du constructeur de copie est généralement supprimable -- mais le constructeur de copie doit rester visible?

(Ceci dit je suis jamais tombé sur ce problème puisque c'est pas courant de déclarer les constructeurs de copie comme étant privé)

C'est au contraire extrèmement courant. C'est rare d'avoir des classes copiables qui ont des fonctions virtuelles.

[David Fleury]

Une création de temporaire par l'appel du constructeur de copie est généralement supprimable -- mais le constructeur de copie doit rester visible?

Je pense que visual supprime cet appel et autorise donc la non visibilité du constructeur. alors que gcc, alors qu'il supprime aussi cet appel, demande la visibilité.

Il n'y a pas une histoire d'optimisation sans effet de bord (que pourrait avoir lieu lors de l'appel à ce constructeur) ?

[Charlemagne]

Pour créer le nouvel objet, il faut appeler son constructeur de copie soit visible (oui, le constructeur de copie qui prend généralement un A const& est traité particulièrement).

Je comprends pas.
Pour créer un nouvel objet, il faut appeler un constructeur tout court, pas son constructeur de copie.

C'est au contraire extrèmement courant. C'est rare d'avoir des classes copiables qui ont des fonctions virtuelles.

Je trouve pas que ce soit si courant que ça. En tout cas l'immense majorité des objets devrait être copiable. Dans la STL c'est le cas. (Toutefois par ex les streams ne sont pas copiables). Une classe non copiable n'est pas une classe "normale".
Et puis le constructeur de copie est défini par défaut.

Je vois pas le rapport avec les fonctions virtuelles, à part le fait que dans ce cas le constructeur de copie ne suffit généralement pas aux besoins, mais qu'il faut un "constructeur de copie virtuel" nommé généralement "clone" dans les bouquins.

[Jean-Marc.Bourguet]

Note: le point d'interrogation est une typo, je ne me pose pas de question la dessus.

Je pense que visual supprime cet appel et autorise donc la non visibilité du constructeur.

Ce qui est clairement un bug.

alors que gcc, alors qu'il supprime aussi cet appel, demande la visibilité.

Ce qui est clairement conforme.

Il n'y a pas une histoire d'optimisation sans effet de bord (que pourrait avoir lieu lors de l'appel à ce constructeur) ?

En regle generale, toute optimisation est autorisee si elle n'est pas detectable par un programme conforme. Dans le cas present, un programme conforme peut la detecter (en comptant le nombre d'appel au constructeur de copie) mais il y a des provisions speciales dans la norme pour l'autoriser.

[David Fleury]

Je trouve pas que ce soit si courant que ça. En tout cas l'immense majorité des objets devrait être copiable. Dans la STL c'est le cas. (Toutefois par ex les streams ne sont pas copiables). Une classe non copiable n'est pas une classe "normale".

Tu remarqueras que les classes de la STL possèdent peu de fonctions virtuelles (à part dans les buffer interne pour les stream justement).

Ce qui est clairement un bug.

Dommage, je le trouvais bien pour une fois leur compilo...

[Charlemagne]

Tu remarqueras que les classes de la STL possèdent peu de fonctions virtuelles (à part dans les buffer interne pour les stream justement).

Bien sûr, mais ça ne répond pas à ma question: pourquoi le constructeur de copie serait nécessaire (mis à part que le standard l'exige) pour un passage par référence constante?
Ni à ma question subsidiaire sur le point soulevé par Jean-Marc: quel est le rapport entre le constructeur de copie et les fonctions virtuelles?

PS: je crois pas que les streams sont non copiables à cause de leurs fonctions virtuelles, mais plutôt que c'est une sécurité pour empêcher l'utilisateur des accès multiples à une unique ressource.

[lun4t1k]

Bah un const par copie est nécessaire si l'on veut éviter une copie champ par champ qu'impose celui par défaut.

J'ai peut etre pas tout compris le problème.

[Charlemagne]

J'ai peut etre pas tout compris le problème.

Je confirme