Deux questions sont déplacées dans une pièce ici ...
J'ai un certain nombre de fonctions appelées plusieurs fois par image pour une application de traitement vidéo en temps réel. En prenant des conseils sur Const et Pass par référence, les fonctions ont une signature quelque peu comme celle-ci , alors que je continue à taper quelques caractères supplémentaires, je me demande si cela est surchargé. < / p> Deuxième question, eh bien, sur le sujet de la réussite par référence, dans le mécanisme de créneaux / signaux de QT, passe par référence permet de prévenir la copie d'objets comme dans un appel de fonction normal? < / p>
3 Réponses :
Oui, passez à titre de référence pour la copie des objets. Mais le compilateur peut décider de l'optimiser entièrement et l'instaure passer par valeur si elle produit le même effet. Une telle optimisation est généralement possible si la fonction et le site d'appel sont dans la même unité de traduction, mais certains compilateurs peuvent faire encore plus d'optimisations globales - vous pouvez inspecter l'assemblage émis si vous vous souciez.
C'est pourquoi vous ne devriez vraiment pas passer des types primitifs par référence si vous vous souciez de la performance et que si vous avez vraiment des raisons à cela. Voir Qu'est-ce que l'utilisation des références de conscons-mêmes à Types primitifs? pour la discussion de ce problème.
La seule situation dans laquelle le compilateur pourrait faire cette optimisation, cependant, si l'appelant et la callee sont dans la même unité de traduction.
En fait, non et Visual C ++ le prouve. Ils appellent la génération de code de liaison de liaison. ISO C ++ ne spécifie pas les responsabilités exactes du préprocesseur, du compilateur, de la liaison et de l'exécution.
Oui, ceci est surchargé et aboutira à ce code plus lent que si vous avez passé la valeur INT par la valeur. Un int est quatre octets; Une référence (essentiellement une adresse mémoire) est également également sur quatre octets (sur une machine 32 bits) ou huit octets (sur une machine 64 bits). Donc, vous devrez peut-être réellement passer les informations plus à la fonction - et en outre, vous avez les frais généraux de la déséroférience de la référence.
Si vous passez quelque chose de plus grand qu'un INT, il est plus efficace d'utiliser une référence de const, car vous pouvez passer à seulement quatre ou huit octets au lieu d'avoir à copier l'objet entier.
Edit Concernant Qt: Oui, si la fente prend une référence de const à un objet, la raison est que la raison est de sauvegarder les frais généraux de la copie de l'objet.
première - la différence entre
est: Normalement, une référence Const est transmise en passant un pointeur, l'autre chose est passée en copiant. Après l'appel (du côté de l'appelant), le résultat est égal. Tout ce que vous passez à la fonction n'est pas modifié par l'appel.
Dans la fonction, vous ne verrez aucune différence (au moins sur un int). Sur les objets, vous ne pouvez utiliser que des fonctions constantes bien sûr.
sur le côté de la performance - passer une référence constante à un INT peut (ou peut ne pas) être plus lent, en fonction du compilateur et de l'optimisation. Le compilateur pourrait (en théorie) optimiser le passage de la référence constante loin à la valeur d'une réussite, je ne sais pas si cela le fait. Travailler avec des pointeurs vers des INT au lieu de valeurs est plus lent bien sûr.
Pour plus d'informations à ce sujet, voir: quand utiliser des pointeurs et quand non Pour les utiliser
Après avoir lu l'autre post lié - le compilateur ne peut pas l'optimiser dans un environnement multithread. Au moins dans un environnement MT, il y a de véritables différences entre les appels INT ET et INT. +1 pour ce lien.
En fait, vous ne pouvez pas utiliser les fonctions de non-const sur le const int & valse non plus. C'est-à-dire que si j'ai void foo (int &) , puis processus (const int & valeur) {foo (valeur); } est illégal mais processus (int VALEUR) {FOO (valeur); } est légal.
Tous les conseils concernant le const et la réussite par référence que j'ai lu ont toujours inclus la réserve "Sauf pour les types intégrés".