2010-02-08 13 views
7

Il y a quelques années, je pensais que C était absolument pur comparé à C++ parce que le compilateur ne pouvait pas générer de code que vous ne pouviez pas prédire. Je crois maintenant que les contre-exemples incluent les barrières de mot-clé et de mémoire volatile (dans la programmation multiprocesseur ou les pilotes de périphériques pour les périphériques matériels mappés en mémoire, où le langage assembleur serait encore plus pur que les optimisations d'un compilateur C). En ce moment j'essaye d'énumérer les choses imprévisibles qu'un compilateur C++ peut faire. La principale plainte qui me vient à l'esprit à propos de C++ est que le compilateur instancie implicitement les objets temporaires, mais je pense que ces cas peuvent tous être attendus. Les cas je pense sont:Comment créer accidentellement des objets temporaires en C++?

  • lorsqu'une classe définit un constructeur de copie pour un type autre que lui-même, sans utiliser le explicit mot-clé
  • lorsqu'une classe définit un opérateur de conversion surchargé: operator()
  • lorsqu'une fonction accepte un objet en valeur plutôt que par référence
  • lorsqu'une fonction retourne un objet par valeur plutôt que par référence

sont la re les autres?

+0

+1: intéressant en ce qui concerne les systèmes embarqués. – jldupont

+3

Ils sont tous définis dans la norme et peuvent donc être prédits - ceux qui ne peuvent être prédits sont des comportements indéfinis – Mark

+1

En C, vous avez des conversions implicites (cast), donc je ne dirais pas que c'est "pure". – Manuel

Répondre

2

Je suppose que "imprévisible" signifie "quelque chose en accord avec la norme mais différent de ce que le programmeur attend pour écrire du code", n'est-ce pas?

Je suppose que vous pouvez voir à partir du code où les objets sont instanciés ou copiés, même si ce n'est peut-être pas évident. Cela pourrait être difficile à comprendre.

Certaines choses sont implémentées de différentes manières par (tous?) Les fournisseurs de compilateurs, mais cela pourrait être fait différemment. Par exemple, la liaison tardive (appeler une méthode virtuelle surchargée) est généralement implémentée en utilisant des pointeurs de fonction en arrière-plan. C'est peut-être le moyen le plus rapide de le faire, mais je suppose que cela pourrait être fait différemment et ce serait inattendu. Je ne connais aucun compilateur mais cela fonctionne différemment. Beaucoup de choses sont inattendues dans le sens où C++ est trop complexe - presque personne ne comprend le langage complet. Donc inattendu dépend aussi de vos connaissances.

+0

+1 pour une bonne analyse de ce qui semble être le problème de la compréhension de la question. –

2

12,2 objets temporaires

1 Temporaries de type de classe sont créés dans divers contextes: un liant rvalue à une référence (8.5.3), renvoyant un rvalue (6.6.3), une conversion qui crée une valeur (4.1, 5.2.9, 5.2.11, 5.4), en lançant une exception (15.1), en entrant un gestionnaire (15.3), et en certaines initialisations (8.5).

4 Il y a deux contextes dans lesquels sont détruits à temporaires un autre point que la fin de la fullexpression.

En fait, je suggère de jeter un oeil à l'ensemble de 12.2

En ce moment je suis en train d'énumérer les choses imprévisibles un compilateur C++ peut faire. La plainte principale qui colle dans mon esprit sur C++ est que le compilateur impliquera implicitement instancier des objets temporaires, mais je pense que ces cas peuvent tous être prévu.

Le compilateur ne crée pas implicitement des temporaires - il obéit à la norme. Sauf, bien sûr, lorsque vous invoquez un comportement indéfini. Notez qu'il existe quelque chose appelé copy-elision et l'optimisation de la valeur de retour qui peut effectivement réduire le nombre de temporaires qui seraient créés autrement.

Questions connexes