Pourquoi est-ce
valide scô mais pas C valide?
Pourquoi est-ce
valide scô mais pas C valide?
Le C et le C++ dire des choses différentes sur le résultat de l'préfixe ++. En C++:
L'opérande de préfixe ++ est modifié par l'ajout de 1. L'opérande doit être modifiable lvalue. Le type de l'opérande doit être une opération arithmétique type de cv bool, ou un pointeur sur un objet défini type. Le résultat est la mise à jour de l'opérande; c'est une lvalue, et c'est un peu-champ si l'opérande est un peu de champ. L'expression ++x est équivalent à x+=1.
Donc ++ peut être appliqué sur le résultat de nouveau, parce que le résultat est tout simplement de l'objet est incrémenté et est une lvalue. Dans C cependant:
L'opérande de l'préfixe d'incrémentation ou de décrémentation opérateur aura atomique, qualifiés ou non qualifiés réel ou de type pointeur, et doit être modifiable lvalue.
La valeur de l'opérande de le préfixe de l'opérateur ++ est incrémenté. L' le résultat est la nouvelle valeur de l'opérande après incrémentation.
Le résultat n'est pas une lvalue, c'est juste de la pure valeur de l'incrémentation. Donc vous ne pouvez pas appliquer n'importe quel opérateur qui nécessite une lvalue, y compris ++.
Si vous êtes jamais dit que le C++ et C sont sur-ensemble ou sous-ensemble des uns des autres, de savoir qu'il n'est pas le cas. Il ya beaucoup de différences qui font que cette affirmation est fausse.
En C, il l'a toujours été. Peut-être parce que pré-incrémenté ++
peut être optimisé pour une seule machine d'instruction en code sur de nombreux Processeurs, y compris à partir des années 1970 qui était quand l' ++
concept développé.
En C++, il n'y a de la symétrie avec la surcharge d'opérateur à prendre en compte. Pour correspondre à C, la structure canonique de la pré-incrémentation ++
serait nécessaire de revenir const &
, sauf si vous avez eu des comportements différents définis par l'utilisateur et les types intégrés (ce qui serait une odeur). Restreindre le retour à l' const &
est une machination. De sorte que le retour de l' ++
obtient détendu de la C règles, au détriment de l'augmentation de compilateur de la complexité afin d'exploiter une unité centrale d'optimisations pour des types intégrés.
Je suppose que vous comprenez pourquoi il est bien en C++ donc je ne vais pas approfondir sur le sujet.
Pour ce qu'il vaut, voici le résultat de mon test:
t.c:6:2: error: lvalue required as increment operand
++ ++c;
^
Concernant CppReference:
Non lvalue les expressions d'objet
Familièrement connu sous le nom rvalues, non lvalue les expressions d'objet sont les expressions de types d'objet qui ne désignent pas des objets, mais plutôt des valeurs qui n'ont pas d'identité de l'objet ou de l'emplacement de stockage. L'adresse d'un non-lvalue objet expression ne peut pas être pris.
Les expressions suivantes sont non-lvalue les expressions d'objet:
tous les opérateurs n'est pas spécifié pour revenir lvalues, y compris
- d'incrémentation et de décrémentation les opérateurs (remarque: le pré - formes sont lvalues en C++)
Et de l'Article 6.5.3.1 de n1570:
La valeur de l'opérande de le préfixe de l'opérateur ++ est incrémenté. Le résultat est la nouvelle valeur de l'opérande après incrémentation.
Donc, en C, le résultat de préfixe d'incrémentation et de préfixe de décrémentation les opérateurs sont pas tenus d'être lvalue, donc pas incrementable de nouveau. En fait, ce mot peut être compris comme "nécessaire pour être rvalue".
Les autres réponses expliquer la façon dont les normes divergent en ce qu'ils exigent. Cette réponse fournit un exemple motivant dans le domaine de la différence.
En C++, vous pouvez avoir une fonction comme int& foo(int&);
, ce qui n'a pas d'analogue dans C. Il est utile (et pas onéreuse) pour C++ d'avoir la possibilité d' foo(foo(x));
.
Imaginez un instant que les opérations sur les types de base ont été définis quelque part, par exemple, int& operator++(int&);
. ++++x
lui-même n'est pas un exemple motivant, mais il correspond à la tendance de l' foo
- dessus.
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.