Les noms ont champ d'application (une propriété à la compilation), tandis que les objets ont durées de vie (une propriété d'exécution). C'est bien cela ?
Je vois souvent des gens parler d'objets temporaires qui "sortent du champ d'application". Mais comme un objet temporaire n'a pas de nom, je pense qu'il est absurde de parler de "portée" dans ce contexte. La durée de vie d'un objet temporaire est de très clairement définie et n'a rien à voir avec le champ d'application. Êtes-vous d'accord ?
Les noms ont une portée (une propriété à la compilation),
Oui, mais je ne dirais pas qu'il s'agit d'une idée de propriété. Mais en gros, oui.
tandis que les objets ont une durée de vie (une propriété d'exécution). C'est bien cela ?
Il existe trois types de variables. Chaque type a des propriétés différentes en ce qui concerne les durées de vie.
Note : les objets de durée de stockage automatique ont une durée de vie liée à la portée de la variable.
Je vois souvent des gens parler d'objets temporaires qui "sortent du champ d'application".
A moins d'être lié à une variable, un temporaire est détruit à la fin d'une expression. S'il est lié à une variable (une référence constante), il a la même durée de vie que la variable. Parfois, il est plus facile de se référer à la portée, mais techniquement vous avez raison.
Mais comme un objet temporaire n'a pas de nom, je pense qu'il est absurde de parler de "portée" dans ce contexte.
Techniquement, oui. Mais je pense qu'il est plus facile d'en parler. Pour moi (bien que ce ne soit pas techniquement correct), la portée d'un temporaire (non lié) est l'expression. C'est plus facile à dire que la durée de vie de la variable temporaire.
La durée de vie d'un objet temporaire est très clairement définie et n'a rien à voir avec la portée. Êtes-vous d'accord ?
Oui, mais il semble plus naturel de parler de champ d'application (même si ce n'est pas techniquement correct). La plupart des gens comprennent ce que vous essayez d'impliquer. Mais lorsque l'on aborde des sujets très techniques, il convient d'utiliser la terminologie correcte et, dans ce contexte, le terme "champ d'application" n'est pas correct.
La durée de vie des temporaires n'a pas grand-chose à voir avec les blocs syntaxiques, mais la "portée" - en tant que mot et non en tant que terme technique - peut être utilisée d'autres manières. La question importante est de savoir si vous êtes confus lorsque les gens utilisent "scope" pour se référer aux temporaires. (Il ne semble pas que ce soit le cas, d'après mon point de vue).
Puisque vous parlez d'utiliser le terme pour communiquer avec les autres, c'est cette communication qui est vraiment importante. Si vous définissiez des termes en rédigeant un document normatif ou en essayant d'interpréter un tel document dans le contexte des termes définis, la situation serait différente. L'interprétation de la norme ISO 14882 impliquera, bien entendu, une communication avec d'autres personnes, de sorte qu'il suffira de demander une clarification si nécessaire, dans ce cas.
Il est contre-productif d'exiger que toutes les communications en langage non standard soient en langage standard, et il est souvent préférable d'utiliser du code en soit lorsqu'une grande précision est requise. La norme C++ utilise largement des exemples pour cette raison.
Autre exemple, on utilise souvent l'expression "appeler un constructeur", alors que, techniquement, on ne peut pas appeler un constructeur directement ; les constructeurs font partie de l'initialisation de l'objet. C'est pourquoi il existe une forme explicite de new uniquement pour construire un objet. (Cependant, je m'attends à ce que cette phrase soit comprise dans la plupart des contextes, bien que je ne préconise pas son utilisation dans les contextes standardisés.
J'ai vu des gens dire qu'"un objet est sorti du champ d'application" alors que cela signifiait (dans votre langage) "la durée de vie de l'objet s'est terminée lorsque le nom de l'objet est sorti du champ d'application". Si vous utilisez cette forme abrégée, il est naturel de dire que les objets temporaires sortent également du champ d'application.
Les objets temporaires ont des noms, bien qu'ils ne puissent être référencés que par le compilateur. Sinon, comment le compilateur pourrait-il s'y référer ? Ce n'est pas parce que vous ne pouvez pas faire référence à un objet temporaire une fois qu'il est instancié que le compilateur ne peut pas y faire référence.
f(Foo(), Bar());Le compilateur doit faire référence à au moins un des temporaires, même si vous, en tant que programmeur, ne pouvez faire référence à aucun d'entre eux. Les objets temporaires ont une portée.
La liaison à une référence constante étend la durée de vie d'une référence temporaire à la durée de vie de la référence. fait ont quelque chose à voir avec le champ d'application dans ce cas particulier :
std::string foo();
int main()
{
// Lifetime of the temporary returned by foo is indeed the scope of bar
const std::string &bar = foo();
}Voir cet article de Herb Sutter :
En règle générale, un que jusqu'à la fin de la période de dans laquelle il apparaît. Cependant, le C++ spécifie délibérément que la liaison d'un objet temporaire à un référence à const sur la pile allonge la durée de vie de l'objet tem elle-même, et évite ainsi ce qui ce qui serait autrement un une erreur courante de dangling-reference.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
