Discussion :

[180degrés]

Bonjour !
Je me pose souvent la question en programmant, si je déclare mon objet en tant que pointeur son exécution sera t elle plus rapide ?
Dans quels faut il se passer des pointeurs ? et inversement ?

[Luc Hermitte]

Tu ne te poses pas la bonne question.
On va utiliser des pointeurs selon de la sémantique de l'objet manipulé ou selon ce que l'on veut en faire à un instant donné.
La performance n'entre pas dans l'équation qui va nous faire décider si l'on doit utiliser pointeur ou objet automatique -- du moins certainement pas dans un premier, ni même dans un second temps.

[180degrés]

merci mais est-ce que tu pourrais me détailler plus ?
Je suis pas très calé sur le sujet

[David Fleury]

Salut,
la FAQ C++ est pas mal à ce propos, non ?
http://c.developpez.com/faq/cpp/?pag...CE_utilisation

En gros, c'est pas un problème de performance mais plutôt de ce que tu veux en faire. Les pointeurs permettent la valeur 0, l'allocation
pour le reste les références suffisent. Sauf erreur de ma part. of course

[bruno_pages]

Je me pose souvent la question en programmant, si je déclare mon objet en tant que pointeur son exécution sera t elle plus rapide ?

Pour répondre strictement à ta 1ère question l'accès à un objet (au sens large, ie quelque chose) via un pointeur sur celui-ci (éventuellement 'déguisé' via une référence par &) est forcement plus long car il y a une lecture en plus pour traverser l'indirection.

[180degrés]

ok merci pour vos réponses, je vais jeter un oeil a la faq aussi.

[diogene]

Pour compléter, si tu dois passer un objet un peu volumineux en paramètre d'une fonction, le processus de recopie peut être couteux en temps et mémoire et tu peux avoir intérêt à passer une référence (éventuellement const) ou un pointeur sur l'objet (éventuellement const) pour l'éviter.

[bruno_pages]

absolument !

Si on prend l'exemple des classes de la stl, la passage d'une string par valeur aura peu d'impact car la chaine interne n'est pas recopiée, il n'en est pas de même pour une list vect etc ... qui eux sont recopiés, ce qui peut avior de graves conséquences sur les temps d'exécution.

[David Fleury]

Si on prend l'exemple des classes de la stl, la passage d'une string par valeur aura peu d'impact car la chaine interne n'est pas recopiée

cette affirmation a t-elle un rapport avec une implémentation possible des std::string avec un compteur de référence ?

Si oui, il faudrait préciser le paragraphe du standard imposant cette implémentation. Je ne le connais pas en tout cas. Pour moi, le C++ n'impose pas cette exigence donc cette affirmation n'est pas juste.
(sauf si tu me donnes le paragraphe évidement )[/code]

[Luc Hermitte]

Ce n'est effectivement pas juste.
Voir l'implémentation de la SL de dinkumware qui semble avoir abandonné le COW (Copy on Write).

De part la question originale, je pense que ce sont les bases qui sont à revoir.
- objets pour lesquels ce qui est important c'est la valeur => entités mathématiques (entiers, vecteurs, matrices, ...), chaine de caractères, ... sémantique de valeur ; on s'intéresse essentiellement à la valeur de la variable. Deux données de valeurs différentes sont intrinsèquement différentes.
- variables (entités) pour lesquels on s'interresse plus à leur identité, leur état pouvant changer tandis qu'ils continuent d'être la même entité. Typiquement les objets issus d'une hiérarchie, et qui seront manipulés par référence ((smart-)pointeurs) sémantique de référence.

Après, les pointeurs peuvent avoir un grand intérêt relativement aux durées de vie des objets. Typiquement, un objet qui devra survivre à la portée locale dans laquelle il est créé, gagne à vivre sur le tas. Pour justement éviter les copies ou déléguer le traitement de sa durée de vie à un gestionnaire (on pourrait très bien renvoyer un handle plutôt qu'un pointeur ici).

Mais, si on regarde comment il est idéal de le manipuler, on peut vouloir plutôt faire abstraction de la gestion de son état, et manipuler un objet de plus haut niveau par valeur. Genre une matrice ou une chaine de caractères. Le prix des copies est un détail plus ou moins complexe à régler quand il se pose.
(Blitz++ avait défini plusieurs types de matrices afin de permettre une sémantique de déplacement en sortie de fonction. Avec le futur C++0x, on aura peut-être un nouveau moyen pour définir un type unique supportant la sémantique de déplacement en plus de la sémantique de valeur.
Une bonne alternative pour éviter de payer le prix du COW.)

Soit : on a quelque chose d'hybride. L'objet est manipulé directement (sémantique de valeur) et vit sur la pile, mais son état interne est géré via un pointeur (et donc vit sur le tas). (Evidemment, cette approche n'a aucun sens pour des objets qui ont véritablement une sémantique de référence)


Et évidemment, les pointeurs sont incontournables pour mettre en oeuvre des structures de données de haut niveau (vecteurs, listes, tables associatives, arbres, ...)

Je ne pense pas avoir été exhaustif. C'est juste une petite recette simplifiée, si ce n'est simpliste. Je sais que j'emploie des mots peu communs, mais ils correspondent à des principes clés qui sont vraiment importants dans ce choix de pointeur ou non.

Avec l'expérience, tu verras mieux où et quand utiliser les pointeurs.

[bruno_pages]

Ce n'est effectivement pas juste.
Voir l'implémentation de la SL de dinkumware qui semble avoir abandonné le COW (Copy on Write).

C'est tout a fait regrétable, la recopie d'une string est chère car elle impose une allocation dans le tas (pour la 'vraie' chaine interne). Pour moi toute implémentation réalisant une recopie n'est tout simplement pas digne d'être distribuée

Pour répondre à Hylvenir, C++ n'impose pas non plus que le calcul de 1+2 se fasse en moins d'un million d'années . . .

Mais cela est dans l'air du temps, et le temps est au gachi de l'utilisation de la mémoire et du CPU, bref à Java

[Luc Hermitte]

Le problème est que l'on paie le prix du COW pour tous les accès où il n'y en a pas besoin. Sans parler des locks MT là où on n'en a pas besoin non plus dès que l'on compilerait pour du MT.

Bref, le retour de fonction est plus rapide en l'abscence de RVO efficace, mais les accès aux chaines plus couteux partout aileurs. Soit la majorité du temps.
On a vu mieux comme optimisation.

Ceci dit, ils utilisent un buffer pour les petites chaines, et il semblerait que cela soit efficace. Je n'ai pas fait de mesures personnellement.

[David Fleury]

C'est tout a fait regrétable, la recopie d'une string est chère car elle impose une allocation dans le tas (pour la 'vraie' chaine interne). Pour moi toute implémentation réalisant une recopie n'est tout simplement pas digne d'être distribuée

J'ai l'impression qu'il y avait plus de bug ou de difficulté à mettre en oeuvre cette solution qu'une simple copie, visiblement les implémenteurs préférent abandonner ce chemin. Le passage par référence ou pointeur évite ce problème de création inutile. En plus, un compilateur 'inteligent' pourrait voir l'inutilité de la création et n'utiliser qu'une référence sans création d'une variable temporaire.

Pour répondre à Hylvenir, C++ n'impose pas non plus que le calcul de 1+2 se fasse en moins d'un million d'années . . . Wink

Je regarde dans le standard
Le C++ impose dans sa bibliothèque pas mal de mimina requis pour les implémentations en tout cas.

Mais cela est dans l'air du temps, et le temps est au gachi de l'utilisation de la mémoire et du CPU, bref à Java

ça sent trop le troll ça je ne suis pas sur ce coup là.

et tout ça sur une question de vitesse pointeur/référence... pas sûr que ça aide l'OP