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).
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.
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) ?
Tu as dis que l'élision pouvait se faire "lorsqu'il est démontré qu'il n'avait pas d'effet(s) de bord".
Non. J'ai dit, et je répéte, que pour élider l'appel au constructeur, par la seule application de la régle du comme si, il faut au préalable montrer qu'il n'y a pas d'effets de bord.
On va pas jouer sur les mots... Je comprends bien que mathématiquement ca veut pas dire "seulement quand il n'y a pas d'effet de bord", mais avoue que c'était le sens de ton message.
Ce n'était pas le sens de mon message.
L'élision peut se faire même quand il y a effet de bord !
Oui.
Comme tu lis mieux Gabriel que moi, je te renvoie à <news: et à <news: dernière phrase, c'est le sens de mon message.
-- Franck Branjonneau
"Vincent Lascaux" <nospam@nospam.org> écrivait:
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.
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) ?
Tu as dis que l'élision pouvait se faire "lorsqu'il est démontré qu'il
n'avait pas d'effet(s) de bord".
Non. J'ai dit, et je répéte, que pour élider l'appel au constructeur,
par la seule application de la régle du comme si, il faut au préalable
montrer qu'il n'y a pas d'effets de bord.
On va pas jouer sur les mots... Je comprends bien que
mathématiquement ca veut pas dire "seulement quand il n'y a pas
d'effet de bord", mais avoue que c'était le sens de ton message.
Ce n'était pas le sens de mon message.
L'élision peut se faire même quand il y a effet de bord !
Oui.
Comme tu lis mieux Gabriel que moi, je te renvoie à
<news:xajadvcopso.fsf@perceval.inria.fr> et à
<news:fl3d0y7huv.fsf@riz.cmla.ens-cachan.fr> dernière phrase, c'est le
sens de mon message.
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.
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) ?
Tu as dis que l'élision pouvait se faire "lorsqu'il est démontré qu'il n'avait pas d'effet(s) de bord".
Non. J'ai dit, et je répéte, que pour élider l'appel au constructeur, par la seule application de la régle du comme si, il faut au préalable montrer qu'il n'y a pas d'effets de bord.
On va pas jouer sur les mots... Je comprends bien que mathématiquement ca veut pas dire "seulement quand il n'y a pas d'effet de bord", mais avoue que c'était le sens de ton message.
Ce n'était pas le sens de mon message.
L'élision peut se faire même quand il y a effet de bord !
Oui.
Comme tu lis mieux Gabriel que moi, je te renvoie à <news: et à <news: dernière phrase, c'est le sens de mon message.
-- Franck Branjonneau
Gabriel Dos Reis
Franck Branjonneau writes:
[...]
| Comme tu lis mieux Gabriel que moi, je te renvoie à | <news: et à | <news: dernière phrase, c'est le | sens de mon message.
Le mot clé étant:
# | C'est-à-dire une règle du "comme si" sans exception.
# Ah, si tu veux une règle sans exception, tu peux considérer, # *en pratique*, que le point 12.8/15 fait partie de la règle « comme # si ».
et la réalité est que la règle du « comme si » n'est pas comme Arnaud le voudrait.
-- Gaby
Franck Branjonneau <fasbjx@free.fr> writes:
[...]
| Comme tu lis mieux Gabriel que moi, je te renvoie à
| <news:xajadvcopso.fsf@perceval.inria.fr> et à
| <news:fl3d0y7huv.fsf@riz.cmla.ens-cachan.fr> dernière phrase, c'est le
| sens de mon message.
Le mot clé étant:
# | C'est-à-dire une règle du "comme si" sans exception.
# Ah, si tu veux une règle sans exception, tu peux considérer,
# *en pratique*, que le point 12.8/15 fait partie de la règle « comme
# si ».
et la réalité est que la règle du « comme si » n'est pas comme
Arnaud le voudrait.
| Comme tu lis mieux Gabriel que moi, je te renvoie à | <news: et à | <news: dernière phrase, c'est le | sens de mon message.
Le mot clé étant:
# | C'est-à-dire une règle du "comme si" sans exception.
# Ah, si tu veux une règle sans exception, tu peux considérer, # *en pratique*, que le point 12.8/15 fait partie de la règle « comme # si ».
et la réalité est que la règle du « comme si » n'est pas comme Arnaud le voudrait.
-- Gaby
Gabriel Dos Reis
James Kanze writes:
[...]
| > Qu'est ce que la norme dit à propos du NRVO ? Est ce qu'elle est très | > générale genre "on peut ommettre une copie et une destruction même si | > ca entraine un changement du comportement du programme", ou est ce | > qu'elle est plus précise et ne permet ca que pour les valeurs de | > retour des fonctions ? | | En ce qui concerne le NRVO, je crois en effet qu'elle se limite aux | valeurs de retour des fonctions. Je sais qu'à un moment donné, les | règles concernant de telles optimisations étaient plus libérales, mais | quelqu'un a trouvé un cas où elles surprenaient. Si je lis le texte | actuel (§12.8/15), j'ai l'impression que la décision finale du comité | était de minimiser la risque de permettre quelque chose d'inattendu, | quitte à interdire certains cas d'optimisation qui serait sûr.
Comme ?
Aussi, il faut se garder d'identifier §12.8/15 à NRVO.
-- Gaby
James Kanze <kanze@none> writes:
[...]
| > Qu'est ce que la norme dit à propos du NRVO ? Est ce qu'elle est très
| > générale genre "on peut ommettre une copie et une destruction même si
| > ca entraine un changement du comportement du programme", ou est ce
| > qu'elle est plus précise et ne permet ca que pour les valeurs de
| > retour des fonctions ?
|
| En ce qui concerne le NRVO, je crois en effet qu'elle se limite aux
| valeurs de retour des fonctions. Je sais qu'à un moment donné, les
| règles concernant de telles optimisations étaient plus libérales, mais
| quelqu'un a trouvé un cas où elles surprenaient. Si je lis le texte
| actuel (§12.8/15), j'ai l'impression que la décision finale du comité
| était de minimiser la risque de permettre quelque chose d'inattendu,
| quitte à interdire certains cas d'optimisation qui serait sûr.
Comme ?
Aussi, il faut se garder d'identifier §12.8/15 à NRVO.
| > Qu'est ce que la norme dit à propos du NRVO ? Est ce qu'elle est très | > générale genre "on peut ommettre une copie et une destruction même si | > ca entraine un changement du comportement du programme", ou est ce | > qu'elle est plus précise et ne permet ca que pour les valeurs de | > retour des fonctions ? | | En ce qui concerne le NRVO, je crois en effet qu'elle se limite aux | valeurs de retour des fonctions. Je sais qu'à un moment donné, les | règles concernant de telles optimisations étaient plus libérales, mais | quelqu'un a trouvé un cas où elles surprenaient. Si je lis le texte | actuel (§12.8/15), j'ai l'impression que la décision finale du comité | était de minimiser la risque de permettre quelque chose d'inattendu, | quitte à interdire certains cas d'optimisation qui serait sûr.
Comme ?
Aussi, il faut se garder d'identifier §12.8/15 à NRVO.
-- Gaby
Franck Branjonneau
Gabriel Dos Reis écrivait:
Franck Branjonneau writes:
| Comme tu lis mieux Gabriel que moi, je te renvoie à | <news: et à | <news: dernière phrase, c'est le | sens de mon message.
Le mot clé étant:
# | C'est-à-dire une règle du "comme si" sans exception.
# Ah, si tu veux une règle sans exception, tu peux considérer, # *en pratique*, que le point 12.8/15 fait partie de la règle « comme # si ».
et la réalité est que la règle du « comme si » n'est pas comme Arnaud le voudrait.
Ton point est donc que 12.8/15 et as-if sont distincts mais suffisamment proche pour qu'en *pratique* ils ne soient pas distinguables ? Par suffisamment proche j'entends : 12.8/15 mets une contrainte implicite sur le constructeur de copie telle que si elle est respectée alors as-if est applicable.
-- Franck Branjonneau
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
Franck Branjonneau <fasbjx@free.fr> writes:
| Comme tu lis mieux Gabriel que moi, je te renvoie à
| <news:xajadvcopso.fsf@perceval.inria.fr> et à
| <news:fl3d0y7huv.fsf@riz.cmla.ens-cachan.fr> dernière phrase, c'est le
| sens de mon message.
Le mot clé étant:
# | C'est-à-dire une règle du "comme si" sans exception.
# Ah, si tu veux une règle sans exception, tu peux considérer,
# *en pratique*, que le point 12.8/15 fait partie de la règle « comme
# si ».
et la réalité est que la règle du « comme si » n'est pas comme
Arnaud le voudrait.
Ton point est donc que 12.8/15 et as-if sont distincts mais
suffisamment proche pour qu'en *pratique* ils ne soient pas
distinguables ? Par suffisamment proche j'entends : 12.8/15 mets une
contrainte implicite sur le constructeur de copie telle que si elle
est respectée alors as-if est applicable.
| Comme tu lis mieux Gabriel que moi, je te renvoie à | <news: et à | <news: dernière phrase, c'est le | sens de mon message.
Le mot clé étant:
# | C'est-à-dire une règle du "comme si" sans exception.
# Ah, si tu veux une règle sans exception, tu peux considérer, # *en pratique*, que le point 12.8/15 fait partie de la règle « comme # si ».
et la réalité est que la règle du « comme si » n'est pas comme Arnaud le voudrait.
Ton point est donc que 12.8/15 et as-if sont distincts mais suffisamment proche pour qu'en *pratique* ils ne soient pas distinguables ? Par suffisamment proche j'entends : 12.8/15 mets une contrainte implicite sur le constructeur de copie telle que si elle est respectée alors as-if est applicable.
-- Franck Branjonneau
Franck Branjonneau
"Vincent Lascaux" écrivait:
[ void foo(S p) { } ]
struct S { S(const &) { throw "anything"; } }; int main() { S s; foo(s); }
Je suis toujours pas convaincu que le compilateur soit *obligé* de lancer "anything"...
Tu as peut-être raison. Est-ce que throw "anything"; est un comportement observable ?
-- Franck Branjonneau
"Vincent Lascaux" <nospam@nospam.org> écrivait:
[ void foo(S p) { } ]
struct S { S(const &) { throw "anything"; } };
int main() { S s; foo(s); }
Je suis toujours pas convaincu que le compilateur soit *obligé* de lancer
"anything"...
Tu as peut-être raison. Est-ce que throw "anything"; est un
comportement observable ?
struct S { S(const &) { throw "anything"; } }; int main() { S s; foo(s); }
Je suis toujours pas convaincu que le compilateur soit *obligé* de lancer "anything"...
Tu as peut-être raison. Est-ce que throw "anything"; est un comportement observable ?
-- Franck Branjonneau
Gabriel Dos Reis
Franck Branjonneau writes:
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | Comme tu lis mieux Gabriel que moi, je te renvoie à | > | <news: et à | > | <news: dernière phrase, c'est le | > | sens de mon message. | > | > Le mot clé étant: | > | > # | C'est-à-dire une règle du "comme si" sans exception. | > | > # Ah, si tu veux une règle sans exception, tu peux considérer, | > # *en pratique*, que le point 12.8/15 fait partie de la règle « comme | > # si ». | > | > et la réalité est que la règle du « comme si » n'est pas comme | > Arnaud le voudrait. | | Ton point est donc que 12.8/15 et as-if sont distincts mais | suffisamment proche pour qu'en *pratique* ils ne soient pas | distinguables ? Par suffisamment proche j'entends : 12.8/15 mets une | contrainte implicite sur le constructeur de copie telle que si elle | est respectée alors as-if est applicable.
Essentiellement, oui.
-- Gaby
Franck Branjonneau <fasbjx@free.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
|
| > Franck Branjonneau <fasbjx@free.fr> writes:
| >
| > | Comme tu lis mieux Gabriel que moi, je te renvoie à
| > | <news:xajadvcopso.fsf@perceval.inria.fr> et à
| > | <news:fl3d0y7huv.fsf@riz.cmla.ens-cachan.fr> dernière phrase, c'est le
| > | sens de mon message.
| >
| > Le mot clé étant:
| >
| > # | C'est-à-dire une règle du "comme si" sans exception.
| >
| > # Ah, si tu veux une règle sans exception, tu peux considérer,
| > # *en pratique*, que le point 12.8/15 fait partie de la règle « comme
| > # si ».
| >
| > et la réalité est que la règle du « comme si » n'est pas comme
| > Arnaud le voudrait.
|
| Ton point est donc que 12.8/15 et as-if sont distincts mais
| suffisamment proche pour qu'en *pratique* ils ne soient pas
| distinguables ? Par suffisamment proche j'entends : 12.8/15 mets une
| contrainte implicite sur le constructeur de copie telle que si elle
| est respectée alors as-if est applicable.
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | Comme tu lis mieux Gabriel que moi, je te renvoie à | > | <news: et à | > | <news: dernière phrase, c'est le | > | sens de mon message. | > | > Le mot clé étant: | > | > # | C'est-à-dire une règle du "comme si" sans exception. | > | > # Ah, si tu veux une règle sans exception, tu peux considérer, | > # *en pratique*, que le point 12.8/15 fait partie de la règle « comme | > # si ». | > | > et la réalité est que la règle du « comme si » n'est pas comme | > Arnaud le voudrait. | | Ton point est donc que 12.8/15 et as-if sont distincts mais | suffisamment proche pour qu'en *pratique* ils ne soient pas | distinguables ? Par suffisamment proche j'entends : 12.8/15 mets une | contrainte implicite sur le constructeur de copie telle que si elle | est respectée alors as-if est applicable.
Essentiellement, oui.
-- Gaby
kanze
Gabriel Dos Reis wrote:
James Kanze writes:
[...]
| > Qu'est ce que la norme dit à propos du NRVO ? Est ce | > qu'elle est très générale genre "on peut ommettre une | > copie et une destruction même si ca entraine un | > changement du comportement du programme", ou est ce | > qu'elle est plus précise et ne permet ca que pour les | > valeurs de retour des fonctions ?
| En ce qui concerne le NRVO, je crois en effet qu'elle se | limite aux valeurs de retour des fonctions. Je sais qu'à un | moment donné, les règles concernant de telles optimisations | étaient plus libérales, mais quelqu'un a trouvé un cas où | elles surprenaient. Si je lis le texte actuel (§12.8/15), | j'ai l'impression que la décision finale du comité était de | minimiser la risque de permettre quelque chose d'inattendu, | quitte à interdire certains cas d'optimisation qui serait | sûr.
Comme ?
Je ne sais pas au juste. Je n'ai pas suivi la discussion en détail à l'époque, et je m'en souviens encore moins aujourd'hui, mais je sais que la formulation originale était bien plus libérale, et qu'on l'a changé parce qu'il y avait des cas où ça donnait une sémantique surprenante, même dans le cas où les objets avaient bien une sémantique de valeur.
Aussi, il faut se garder d'identifier §12.8/15 à NRVO.
Comme je dis, je ne connais pas les détails. D'un certain point de vue, on peut dire que je fais confiance au comité de ne pas avoir fait une bêtise -- si mes types à valeur se comportent comme des valeurs, tout marche bien, et la seule différence que je peux constater, c'est que mes programmes tournent un peu plus vite.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis wrote:
James Kanze <kanze@none> writes:
[...]
| > Qu'est ce que la norme dit à propos du NRVO ? Est ce
| > qu'elle est très générale genre "on peut ommettre une
| > copie et une destruction même si ca entraine un
| > changement du comportement du programme", ou est ce
| > qu'elle est plus précise et ne permet ca que pour les
| > valeurs de retour des fonctions ?
| En ce qui concerne le NRVO, je crois en effet qu'elle se
| limite aux valeurs de retour des fonctions. Je sais qu'à un
| moment donné, les règles concernant de telles optimisations
| étaient plus libérales, mais quelqu'un a trouvé un cas où
| elles surprenaient. Si je lis le texte actuel (§12.8/15),
| j'ai l'impression que la décision finale du comité était de
| minimiser la risque de permettre quelque chose d'inattendu,
| quitte à interdire certains cas d'optimisation qui serait
| sûr.
Comme ?
Je ne sais pas au juste. Je n'ai pas suivi la discussion en
détail à l'époque, et je m'en souviens encore moins aujourd'hui,
mais je sais que la formulation originale était bien plus
libérale, et qu'on l'a changé parce qu'il y avait des cas où ça
donnait une sémantique surprenante, même dans le cas où les
objets avaient bien une sémantique de valeur.
Aussi, il faut se garder d'identifier §12.8/15 à NRVO.
Comme je dis, je ne connais pas les détails. D'un certain point
de vue, on peut dire que je fais confiance au comité de ne pas
avoir fait une bêtise -- si mes types à valeur se comportent
comme des valeurs, tout marche bien, et la seule différence que
je peux constater, c'est que mes programmes tournent un peu plus
vite.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| > Qu'est ce que la norme dit à propos du NRVO ? Est ce | > qu'elle est très générale genre "on peut ommettre une | > copie et une destruction même si ca entraine un | > changement du comportement du programme", ou est ce | > qu'elle est plus précise et ne permet ca que pour les | > valeurs de retour des fonctions ?
| En ce qui concerne le NRVO, je crois en effet qu'elle se | limite aux valeurs de retour des fonctions. Je sais qu'à un | moment donné, les règles concernant de telles optimisations | étaient plus libérales, mais quelqu'un a trouvé un cas où | elles surprenaient. Si je lis le texte actuel (§12.8/15), | j'ai l'impression que la décision finale du comité était de | minimiser la risque de permettre quelque chose d'inattendu, | quitte à interdire certains cas d'optimisation qui serait | sûr.
Comme ?
Je ne sais pas au juste. Je n'ai pas suivi la discussion en détail à l'époque, et je m'en souviens encore moins aujourd'hui, mais je sais que la formulation originale était bien plus libérale, et qu'on l'a changé parce qu'il y avait des cas où ça donnait une sémantique surprenante, même dans le cas où les objets avaient bien une sémantique de valeur.
Aussi, il faut se garder d'identifier §12.8/15 à NRVO.
Comme je dis, je ne connais pas les détails. D'un certain point de vue, on peut dire que je fais confiance au comité de ne pas avoir fait une bêtise -- si mes types à valeur se comportent comme des valeurs, tout marche bien, et la seule différence que je peux constater, c'est que mes programmes tournent un peu plus vite.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
"kanze" writes:
[...]
| > Aussi, il faut se garder d'identifier §12.8/15 à NRVO. | | Comme je dis, je ne connais pas les détails.
Donnerais-tu des leçons à propos de §12.8/15 sans savoir ce qu'il dit ?
-- Gaby
"kanze" <kanze@gabi-soft.fr> writes:
[...]
| > Aussi, il faut se garder d'identifier §12.8/15 à NRVO.
|
| Comme je dis, je ne connais pas les détails.
Donnerais-tu des leçons à propos de §12.8/15 sans savoir ce qu'il dit ?
| > Aussi, il faut se garder d'identifier §12.8/15 à NRVO. | | Comme je dis, je ne connais pas les détails.
Donnerais-tu des leçons à propos de §12.8/15 sans savoir ce qu'il dit ?
-- Gaby
Franck Branjonneau
Gabriel Dos Reis écrivait:
Franck Branjonneau writes:
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | Comme tu lis mieux Gabriel que moi, je te renvoie à | > | <news: et à | > | <news: dernière phrase, | > | c'est le sens de mon message. | > | > Le mot clé étant: | > | > # | C'est-à-dire une règle du "comme si" sans exception. | > | > # Ah, si tu veux une règle sans exception, tu peux considérer, | > # *en pratique*, que le point 12.8/15 fait partie de la règle « comme | > # si ». | > | > et la réalité est que la règle du « comme si » n'est pas comme | > Arnaud le voudrait. | | Ton point est donc que 12.8/15 et as-if sont distincts mais | suffisamment proche pour qu'en *pratique* ils ne soient pas | distinguables ? Par suffisamment proche j'entends : 12.8/15 mets | une contrainte implicite sur le constructeur de copie telle que si | elle est respectée alors as-if est applicable.
Essentiellement, oui.
Alors, essentiellement, je ne comprends pas
,---- | From: Gabriel Dos Reis | Message-ID: | | 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 `----
La question du superflu reste ouverte...
-- Franck Branjonneau
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
Franck Branjonneau <fasbjx@free.fr> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
|
| > Franck Branjonneau <fasbjx@free.fr> writes:
| >
| > | Comme tu lis mieux Gabriel que moi, je te renvoie à
| > | <news:xajadvcopso.fsf@perceval.inria.fr> et à
| > | <news:fl3d0y7huv.fsf@riz.cmla.ens-cachan.fr> dernière phrase,
| > | c'est le sens de mon message.
| >
| > Le mot clé étant:
| >
| > # | C'est-à-dire une règle du "comme si" sans exception.
| >
| > # Ah, si tu veux une règle sans exception, tu peux considérer,
| > # *en pratique*, que le point 12.8/15 fait partie de la règle « comme
| > # si ».
| >
| > et la réalité est que la règle du « comme si » n'est pas comme
| > Arnaud le voudrait.
|
| Ton point est donc que 12.8/15 et as-if sont distincts mais
| suffisamment proche pour qu'en *pratique* ils ne soient pas
| distinguables ? Par suffisamment proche j'entends : 12.8/15 mets
| une contrainte implicite sur le constructeur de copie telle que si
| elle est respectée alors as-if est applicable.
Essentiellement, oui.
Alors, essentiellement, je ne comprends pas
,----
| From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| Message-ID: <m3hdahwt1f.fsf@uniton.integrable-solutions.net>
|
| Franck Branjonneau <fasbjx@free.fr> 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
`----
| Gabriel Dos Reis écrivait: | | > Franck Branjonneau writes: | > | > | Comme tu lis mieux Gabriel que moi, je te renvoie à | > | <news: et à | > | <news: dernière phrase, | > | c'est le sens de mon message. | > | > Le mot clé étant: | > | > # | C'est-à-dire une règle du "comme si" sans exception. | > | > # Ah, si tu veux une règle sans exception, tu peux considérer, | > # *en pratique*, que le point 12.8/15 fait partie de la règle « comme | > # si ». | > | > et la réalité est que la règle du « comme si » n'est pas comme | > Arnaud le voudrait. | | Ton point est donc que 12.8/15 et as-if sont distincts mais | suffisamment proche pour qu'en *pratique* ils ne soient pas | distinguables ? Par suffisamment proche j'entends : 12.8/15 mets | une contrainte implicite sur le constructeur de copie telle que si | elle est respectée alors as-if est applicable.
Essentiellement, oui.
Alors, essentiellement, je ne comprends pas
,---- | From: Gabriel Dos Reis | Message-ID: | | 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 `----
La question du superflu reste ouverte...
-- Franck Branjonneau
Franck Branjonneau
Franck Branjonneau écrivait:
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 [...] »
L'élision de la copie n'est permise que si les types impliqués sont les « same cv-unqualified type ». Est-ce que cela veut dire que dans l'exemple suivant
N'est-ce pas ennuyeux lorsqu'on applique le conseil de H. Sutter <http://www.gotw.ca/gotw/006.htm> paragraphe 4 : « (Arguable.) Return-by-value should normally be const for non-builtin return types. » ?
Certes, si l'on montre au compilateur que l'on applique la contrainte implicite placée par 12.8/15 sur le constructeur de copie il pourra toujours utiliser as-if. Quoiqu'il en soit g++-4 n'en à cure et retourne 0. Est-ce un bug ?
-- Franck Branjonneau
Franck Branjonneau <fasbjx@free.fr> écrivait:
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 [...] »
L'élision de la copie n'est permise que si les types impliqués sont
les « same cv-unqualified type ». Est-ce que cela veut dire que dans
l'exemple suivant
N'est-ce pas ennuyeux lorsqu'on applique le conseil de H. Sutter
<http://www.gotw.ca/gotw/006.htm> paragraphe 4 : « (Arguable.)
Return-by-value should normally be const for non-builtin return
types. » ?
Certes, si l'on montre au compilateur que l'on applique la contrainte
implicite placée par 12.8/15 sur le constructeur de copie il pourra
toujours utiliser as-if. Quoiqu'il en soit g++-4 n'en à cure et
retourne 0. Est-ce un bug ?
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 [...] »
L'élision de la copie n'est permise que si les types impliqués sont les « same cv-unqualified type ». Est-ce que cela veut dire que dans l'exemple suivant
N'est-ce pas ennuyeux lorsqu'on applique le conseil de H. Sutter <http://www.gotw.ca/gotw/006.htm> paragraphe 4 : « (Arguable.) Return-by-value should normally be const for non-builtin return types. » ?
Certes, si l'on montre au compilateur que l'on applique la contrainte implicite placée par 12.8/15 sur le constructeur de copie il pourra toujours utiliser as-if. Quoiqu'il en soit g++-4 n'en à cure et retourne 0. Est-ce un bug ?
