Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ const & sur les POD

const & sur les POD

34 réponses
Avatar
David F.
Bonjour,
je lis parfois le code suivant (un poste récent le montre d'ailleurs):

1. int fct( const INT& n );

au lieu d'un simple

2. int fct ( INT n );

L'argument pour la forme 1. est (à mon sens):
- elle force la vérification que n ne sera pas
modifiée à l'intérieur de fct.
- elle force un passage sans recopie de n
( plus génant pour un vrai objet)
- elle évité d'avoir à réfléchir si INT est un POD ou un objet
complexe et hésiter entre la forme 1. et 2.

Honnêtement, même si j'utilise la forme 2. pour les POD, et la 1.
pour les objets. J'ai du mal à donner des arguments contre la forme 1
(au delà de la lourdeur de la notation).

Cordialement.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
Fabien LE LEZ
On Mon, 17 Oct 2005 23:51:47 +0200, Franck Branjonneau
:

Message-ID:


Je t'encourage mettre "news:" après le "<" -- certains lecteurs de
news ont du mal s'il n'est pas là.

---> <news:

(Enfin, moi ça m'est égal, Agent s'en sort parfaitement :-) )

Avatar
Franck Branjonneau
"Vincent Lascaux" écrivait:

Le compilo n'est il pas en droit d'inliner ?


Message-ID: <4351803f$0$21699$
Le compilateur a droit à faire tout ce qui ne modifie pas le
comportement visible du programme. S'il peut déterminer que le
résultat en est le même, il peut faire la modification.


Un thread beaucoup plus récent m'a rappelé pourquoi j'avais des doutes : le
compilateur a le droit de faire certaines opérations bien précises qui
modifient le comportement d'un programme.


Tu as mal compris.

Le constructeur de copie peut être supprimé (ca s'appelle NRVO:
named return value optimization).


L'élision de l'appel au constructeur de copie ne modifie pas le
comportement d'un programme. Il fait partie de son comportement.

Le nom semble indiquer que ca ne marche que pour les valeurs de
retour et pas pour les arguments...


Lis <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#20>
« When certain criteria are met, an implementation is allowed to omit
the copy construction of a class object [...] This elision of copy
operations is permitted in the following circumstances (which may be
combined to eliminate multiple copies):
- in a return statement in a function with a class return type [...]
- when a temporary class object (12.2 class.temporary ) would be
copied to a class object with the same cv-unqualified type [...] »

et <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#185>
pour être complet.


La régle du comme si permet l'élision de l'appel au constructeur de
copie lorsqu'il est démontré qu'il n'avait pas d'effet(s) de
bord. 12.8/15 est une démonstration.


Je ne suis toujours pas convaincu que la norme interdise d'éviter
une copie quand un appel à une fonction est inliné.


J'ai eu un peu de mal à comprendre ta question. En reprenant le fil,
je l'ai comprise comme, dans le code qui suit :

struct S {};

inline void foo(S param);

int main() { S var; foo(var); }

est-ce que le compilateur est autorisé à ne pas faire la copie de var
dans param ? en particulier car foo est inline ?

Selon ce que j'en ai compris, que foo soit inline ou non, 12.8/15
n'autorise pas le compilateur à ne pas faire la copie. Il peut
néanmoins ne pas faire la copie si il démontre qu'elle est sans
effet(s) de bord.

--
Franck Branjonneau



Avatar
Franck Branjonneau
"Vincent Lascaux" écrivait:

Un thread beaucoup plus récent m'a rappelé pourquoi j'avais des
doutes : le compilateur a le droit de faire certaines opérations
bien précises qui modifient le comportement d'un programme.


Tu as mal compris.


Si on a le code suivant

class A
{
A(const A& foo) { std::cout << "Copy" << std::endl; }
};
A foo() { return A(); }
int main() { A a = foo(); }

Techniquement on devrait appeller le constructeur par défaut dans foo, le
constructeur par copie pour copier le résultat dans a (ce qui affiche Copy à
l'écran), le destructeur de l'objet retourné par foo et finalement le
destructeur de a. Ce que j'ai compris c'est que le compilateur est en droit
d'appeler le constructeur par défaut de a quand on construit l'objet
retourné, et ainsi éviter une copie et une destruction, et ce même si ca
change le comportement du programme (on n'affiche plus "Copy" à l'écran).

C'est ce que Kanze a voulu dire dans ce message :
news: quand il dit
"C'est une optimisation explicitement permise par la norme, même dans le cas
où il y a changement dans le comportement visuel du programme."


Oui. Ce que je conteste c'est « changement dans le comportement visuel
du programme ». Ce n'est pas un changement, c'est le programme.

L'élision de l'appel au constructeur de copie ne modifie pas le
comportement d'un programme. Il fait partie de son comportement.


Je comprends pas ce que tu veux dire. L'élision de l'appel au constructeur
de copie dans mon exemple plus haut modifie le comportement du programme,
non ?


Il ne le modifie que si tu t'attends à ce qu'il soit appelé. Mais il
n'est pas appelé.

La régle du comme si permet l'élision de l'appel au constructeur de
copie lorsqu'il est démontré qu'il n'avait pas d'effet(s) de
bord. 12.8/15 est une démonstration.


Ce n'est pas comme ca que je comprends le "even if the copy constructor
and/or destructor for the object have side effects."


Et comment le comprends-tu ?

struct S {};
inline void foo(S param);
int main() { S var; foo(var); }

est-ce que le compilateur est autorisé à ne pas faire la copie de var
dans param ? en particulier car foo est inline ?


C'est exactement ma question... Si le corps de foo est vide (void foo(S
param) { }), est ce que le compilateur peut transformer le code en


1/

int main() { S var; }

ou est ce qu'il est obligé (pour conserver la copie du paramètre) de
transformer le code en


2/

int main() { S var; { S param = var; }}



Je dirais 2.

--
Franck Branjonneau



Avatar
Gabriel Dos Reis
Franck Branjonneau writes:

[...]

| La régle du comme si permet l'élision de l'appel au constructeur de
| copie lorsqu'il est démontré qu'il n'avait pas d'effet(s) de
| bord. 12.8/15 est une démonstration.

Non.

-- Gaby
Avatar
Franck Branjonneau
"Vincent Lascaux" écrivait:

C'est ce que Kanze a voulu dire dans ce message :
news: quand il dit
"C'est une optimisation explicitement permise par la norme, même dans le
cas
où il y a changement dans le comportement visuel du programme."


Oui. Ce que je conteste c'est « changement dans le comportement visuel
du programme ». Ce n'est pas un changement, c'est le programme.


L'optimisation induit un changement dans le comportement visuel de
l'execution du code. Le comportement n'est pas le même avec ou sans
l'optimisation. L'optimisation change le comportement visuel. Je sais pas si
on est d'accord et que tu joues sur les mots ou si on n'est vraiment pas
d'accord...


C'est certes un jeu sur les mots et nous sommes sensiblement
d'accord. Notre diffèrence provient du fait que tu considères
l'élision de l'appel au constructeur de copie comme une optimisation
optionnelle, et moi non. Optimisation optionnelle : tu écris du code
pour un compilateur donné, tu sais si il effectue, ou non,
l'optimisation ; et tu écris ton code en conséquence -- avec, ou sans,
effets de bord dans tes constructeurs de copie. Pas d'optimisation :
tu écris du code pour la machine abstraite, tu ignores si il y aura
optimisation ou non ; et tu écris ton code en conséquence -- sans
effets de bord dans tes constructeurs de copie -- tu pré-supposes
l'optimisation qui donc n'en est plus une.

La régle du comme si permet l'élision de l'appel au constructeur de
copie lorsqu'il est démontré qu'il n'avait pas d'effet(s) de
bord. 12.8/15 est une démonstration.


Ce n'est pas comme ca que je comprends le "even if the copy constructor
and/or destructor for the object have side effects."


Et comment le comprends-tu ?


La traduction que j'en ferais serait "Quand certains criteres sont vérifiés,
une implémentation peut ommettre le constructeur par copie d'un "objet
class" (euh ? par opposition à un type de base ?), *même si le constructeur
par copie et/ou le destructeur de l'objet ont des effets de bords*". Je
comprends le "même s'il y a des effets de bords" comme une indication que le
compilateur n'a pas à se soucier du changement de comportement du programme
lorsqu'il fait cette optimisation. Il n'a pas a "démontrer qu'il n'y a pas
d'effets de bord".


N'est pas ce que je dis (en un peu plus fort puisque j'utilise
12.8/15 pour englober l'élision de l'appel au constructeur de copie
dans la règle du comme si) ?

--
Franck Branjonneau




Avatar
Franck Branjonneau
"Vincent Lascaux" écrivait:

Oui, je pense qu'il serait plus interessant de supposer que S a des effets
de bord dans tous ses constructeurs

struct S {
S() { std::cout << "Defaut "; }
S(const S&) { std::cout << "Copie "; }
~S() { std::cout << "Destructeur "; }
};
inline void foo(S) { }
int main() { S var; foo(var); }

Est ce que la sortie du programme est
1) "Defaut Copie Destructeur Destructeur"
2) "Defaut Destructeur"
3) Rien
4) Soit 1) soit 2)
5) N'importe quoi
6) Autre chose

Je pense que la réponse est soit 1 soit 4...


Je dis 1.

--
Franck Branjonneau

Avatar
Franck Branjonneau
Gabriel Dos Reis écrivait:

Franck Branjonneau writes:

[...]

| La régle du comme si permet l'élision de l'appel au constructeur de
| copie lorsqu'il est démontré qu'il n'avait pas d'effet(s) de
| bord. 12.8/15 est une démonstration.

Non.


Veux-tu expliciter ?

--
Franck Branjonneau

Avatar
Gabriel Dos Reis
"Vincent Lascaux" writes:

| > Notre diffèrence provient du fait que tu considères
| > l'élision de l'appel au constructeur de copie comme une optimisation
| > optionnelle, et moi non.
|
| C'est une optimisation optionnelle dans le sens ou c'est une optimisation
| (c'est le O de NRVO) et qu'elle est optionnelle (le compilateur n'est pas
| forcé de l'implémenter).

D'abord, it faudrait se mettre d'accord sur la notion d'optimisation.
Pour moi, une optimisation (the « as-if rule ») ne change pas la
sémantique d'un programme. Ici, la norme donne une licence explicite
pour choisir un autre fonctionnement observable.

-- Gaby
Avatar
Gabriel Dos Reis
"Vincent Lascaux" writes:

| >> | La régle du comme si permet l'élision de l'appel au constructeur de
| >> | copie lorsqu'il est démontré qu'il n'avait pas d'effet(s) de
| >> | bord. 12.8/15 est une démonstration.
| >>
| >> Non.
| >
| > Veux-tu expliciter ?
|
| Il veut dire que la condition qu'il n'y ait pas d'effets de bord dans le
| constructeur de copie ou le destructeur n'est pas necessaire pour appliquer
| le NRVO

Exact.

Et 12.8./15 n'est pas une démonstration de la « as-if rule. »

-- Gaby
Avatar
Franck Branjonneau
Gabriel Dos Reis écrivait:

"Vincent Lascaux" writes:

| >> | La régle du comme si permet l'élision de l'appel au
| >> | constructeur de copie lorsqu'il est démontré qu'il n'avait
| >> | pas d'effet(s) de bord. 12.8/15 est une démonstration.
| >>
| >> Non.
| >
| > Veux-tu expliciter ?
|
| Il veut dire que la condition qu'il n'y ait pas d'effets de bord
| dans le constructeur de copie ou le destructeur n'est pas
| necessaire pour appliquer le NRVO

Exact.


En ce cas, je m'exprime mal.

Et 12.8./15 n'est pas une démonstration de la « as-if rule. »


Je m'exprime vraiment mal.

--
Franck Branjonneau

1 2 3 4