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).
| 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...
(1) si on veut raisonner du point de vue formel de la norme, e.g si tu veux par exemple porter plainte contre ton compilateur, 12.8/15 *n'est pas* une démonstration de la « as-if rule » comme définit par la norme.
(2) si tout ce qui t'interesse, c'est une règle simple, pratique, tu suivras en tant que programmeur, voir la réponse à Arnaud à laquelle tu faisais allusion. Le mot clé étant *pratique*.
C'est plus clair ?
-- Gaby
Franck Branjonneau <fasbjx@free.fr> writes:
| 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
| `----
|
| La question du superflu reste ouverte...
(1) si on veut raisonner du point de vue formel de la norme, e.g si
tu veux par exemple porter plainte contre ton compilateur,
12.8/15 *n'est pas* une démonstration de la « as-if rule » comme
définit par la norme.
(2) si tout ce qui t'interesse, c'est une règle simple, pratique, tu
suivras en tant que programmeur, voir la réponse à Arnaud à
laquelle tu faisais allusion. Le mot clé étant *pratique*.
| 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...
(1) si on veut raisonner du point de vue formel de la norme, e.g si tu veux par exemple porter plainte contre ton compilateur, 12.8/15 *n'est pas* une démonstration de la « as-if rule » comme définit par la norme.
(2) si tout ce qui t'interesse, c'est une règle simple, pratique, tu suivras en tant que programmeur, voir la réponse à Arnaud à laquelle tu faisais allusion. Le mot clé étant *pratique*.
C'est plus clair ?
-- Gaby
Franck Branjonneau
Gabriel Dos Reis écrivait:
Franck Branjonneau writes:
[...]
C'est plus clair ?
Je m'en satisferais. Merci.
Si tu as le temps de répondre à <news:. Que je saches si je fais un bug report.
-- Franck Branjonneau
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait:
Franck Branjonneau <fasbjx@free.fr> writes:
[...]
C'est plus clair ?
Je m'en satisferais. Merci.
Si tu as le temps de répondre à
<news:873blzully.fsf@alpha.tchume.net>. Que je saches si je fais un
bug report.
Si tu as le temps de répondre à <news:. Que je saches si je fais un bug report.
-- Franck Branjonneau
kanze
Franck Branjonneau wrote:
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
Non. La valeur de rétour et t2 ont le même cv-unqualified type : Thing. La valeur de rétour de main peut donc être 0, 1 ou 2.
-- 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
Franck Branjonneau wrote:
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
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
