Version imprimable
Bonjour,
Je voudrai savoir si de déclarer des variables dans une boucle - comme for - fait ralentir le système, ou c'est négligeable.
N'est-il pas préférable de déclarer sa variable avant la boucle, et de la remettre à zéro s'il le faut ? y a un t-il un réel coup physique de déclarer sa variable ou non dans une boucle ?
Lors d'un deuxième tour de boucle, la déclaration se fait de nouveau, l'espace pris avant est supprimé ? le système prend-il la même adresse que précedement ?
merci d'avance
Bonjour,
C'est une question pertinente, que trop de gens « négligent » effectivement aujourd'hui mais, dans le cas présent, c'est négligeable, car ta variable va être déclarée dans la pile, puis accédée via un offset par rapport à un pointeur de base. Et l'allocation d'espace dans cette pile se fait simplement en soustrayant la taille de l'espace nécessaire. Donc, la différence entre les deux se résumera simplement à des valeurs d'offset différentes. Réinitialiser la variable a bien sûr un coût (faible), mais tu nous informes que tu le fais de toutes façons.
C'est donc une bonne chose de garder, en C, ses variables le plus « localement » possible pour réduire au minimum la taille instantanée de la pile, et ça devient même salutaire sur de gros projets. GCC propose même un flag pour nous alerter lorsqu'une variable en masque une autre de même nom mais de plus haut niveau, ce qui est pourtant parfaitement légal (et même utile) en C. Ça nous a sauvés plusieurs fois.
En revanche, ce n'est pas du tout le cas de manière universelle, et ça l'est même très rarement sur les langages interprétés, et mêmes les langages compilés de plus haut niveau comme Java ou même C++ lorsque tu instancies des objets, à cause du RAII : chaque re-déclaration d'objet effectivement le rappel du constructeur et tout le processus interne qui s'en suit, comme des allocations diverses. Dans ce genre d'environnement, il vaut mieux privilégier la réutilisation des objets lorsqu'ils dépassent les simples types natifs.
okay, donc faire au mieux déclarer sa variable le plus tard, mais si je déclare ma variable en début de bloc, et qu'à partir de ma boucle, je me retrouve à nouveau au niveau de la déclaration, il y a automatiquement liberation de mémoire de l'ancien, et nouvel emplacement pour la nouvelle variable ?
et donc y a t-il une importance de déclarer en milieu de bloc, en début ou en fin ?
Non. Une variable locale déclarée à la compilation (c'est-à-dire sans faire appel à une fonction explicite comme malloc()) a la durée de vie de son bloc. Elle est visible par tout ce qu'il contient, et seulement par ce contenu (sauf artifices style pointeurs passé à une fonction appelée depuis ce bloc).Citation:
Envoyé par dafpp
En principe, C89 t'oblige à tout déclarer au début d'un bloc, avant la première ligne de code. Et ceci justement parce que l'on avait besoin de connaître à l'avance la taille du cadre de pile pour pouvoir générer en conséquence le code qui va l'utiliser. Depuis, des normes plus récentes ont levé cette restriction, mais c'est toujours une bonne idée de t'y contraindre si tu codes en C. C'est plus facile de s'y retrouver ensuite, et ça permettra à donc programme de compiler partout.Citation:
et donc y a t-il une importance de déclarer en milieu de bloc, en début ou en fin ?
Je vois donc, de toute façon, peu importe où je déclare ma variable, tout ce qui est déclaré a son forcement son espace mémoire, même si on va jamais dans ce bloc.
Donc je déclare tout en début de fonction, et je fais attention à remettre l'espace mémoire à zéro.
merci :ccool:
edit: j'y pense mais ce qui est des déclarations de variables en début de bloc, sur quel système ça ne marcherait peut-être pas ? et si oui pourquoi ? Tant que le compilo prend en compte la norme C89 c'est bon ?
J'ai un gros doute sur le fait que chaque fois que l'on rentre dans un bloc (if for while...) la pile bouge... Je ne sais pas si c'est spécifié dans le standard du langage ou de l'ABI, mais il faudrait que je trouve confirmation de cela...Citation:
Envoyé par Obsidian
A noter aussi que certaines variables peuvent êtres mises dans des registres et ne jamais exister en mémoire...
Tout cela ne répond pas directement à ta question, mais bon, j'ai un doute qui me fait me réveiller là.
Ce qui fait grandir mon doute aussi, et qui peut influencer ma façon de faire.
Donc j'attends une réponse à ton psot.
à vrai dire, on s'en fiche, si c'est dans la pile où pas..
Ce n'et pas l'argument pour cette manière de faire.
L'argument est de ne définir des variables que là où on en a besoin.
Personnellement (mais je suis de la vieille école) je préfère faire "à la C89", et définir toutes mes variables en début de fonction. Je trouve cela plus "maintenable" .. et avec un point de vue global sur ce qu'utilise la fonction.
Maintenant, la politique de cerner au plus près se défend également, bien que je trouve cela moins "maintenable" et plus difficile à lire/comprendre. Mais ce point de vue est personnel..
En tous cas, le fait que cela soit sur la pile ou non n'est pas l'argument pour lequel cela a été inclus en C99.. : c'est celui de la portée.
Bon, c'est un long débat qu'on a déjà eu à plusieurs reprises. Personnellement, je préfère définir une variable à un moment où je suis en mesure de l'initialiser avec une valeur qui fait sens, et éventuellement la définir avec le qualificatif const, si ça aide à document mon intention. Dans cette mesure, restreindre la portée d'une variable au bloc où elle est utilisée me semble une bonne pratique.
A noter que C90 n'oblige aucunement de définir ses variables en début de fonction, mais en début de bloc. Ainsi, même en C90, je trouve que c'est une bonne pratique de restreindre au maximum la portée d'une variable à l'endroit où elle est utilisée et où elle peut être initialisée avec une valeur qui fait sens.
Je comprends et respecte toutefois les arguments de souviron34, qui se défendent et qui sont partagés par beaucoup de monde. Personnellement, si une variable n'est utilisée que dans le corps d'une boucle, je n'hésiterais pas à la définir dans la boucle. Le overhead, du point de vue de la performance, ne doit effectivement pas être significatif.
Avec mes meilleures salutations
Thierry
Que la pile bouge ou non au sein d'un tour d'un même tour de boucle importe peu en C. Par contre, c'est nécessaire quand tu passes d'un bloc à l'autre et que ceux-ci sont situés au même niveau, c'est-à-dire : inclus dans un même troisième bloc. Si depuis un bloc A, je rentre dans un bloc B et que j'y déclare un gros tableau de 512 ko, lorsque je quitte le bloc, je m'attends effectivement à ce que ces 512 ko soient libérés, ne serait-ce que parce que je peux avoir envie de déclarer un autre gros tableau dans le bloc suivant.Citation:
Envoyé par valefor
Après, le compilateur peut faire des optimisations s'il a une vision suffisamment lointaine du déroulement de ta séquence, mais cela ne peut pas être une généralité, ne serait-ce que parce qu'entre les deux, tu peux avoir besoin d'appeler une fonction par exemple.
Et cela devient même critique lorsque tu utilises des fonctions récursives : il est courant d'avoir plusieurs points de réentrance dans une telle fonction et si le compilateur prévoit systématiquement au plus large, on risque d'atteindre les limites des ressources bien avant de les avoir réellement toutes utilisées.
je ne sais pas si la norme impose un nouveau cadre de pile pour chaque bloc, mais je suis certain que c'est le cas si ce bloc est le corps d'une fonction.
pour faire
bloc A{je pense qu'on peut faire
bloc B
bloc C
}
definir fonction Abloc A
definir fonction B{pour que les cadres de pile soient différents.
call B;
call C;
}
A+
Oui mais en l'occurence, on traite du problème opposé : on veut savoir si la pile reste ou non constante lorsque l'on navigue d'un bloc à l'autre au sein d'une même fonction.Citation:
Envoyé par anacharsis
Ce que la norme dit, c'est que la durée de vie d'un l'objet non VLA commence au début du bloc (même si la déclaration n'est pas en début de bloc) jusqu'à la fin du bloc où il est défini. Pour les VLA, du point de sa déclaration à la fin du bloc où il est déclaré.
Pour un VLA, l'espace mémoire ne peut être alloué qu'au début de sa durée de vie (il faut bien connaitre sa taille pour le créer) et je pense que c'est également vrai pour les autres (pourquoi en serait-il autrement ?)
Cela t'importe peu, mais j'imagine que si la pile bouge à chaque fois que tu entres dans un bloc (autre que fonction), tu te poserais des questions niveau performances...Citation:
Envoyé par Obsidian
Si les variables sont effectivement poussées sur la pile des qu'on rentre dans un bloc j'imagine qu'au niveau de l'ABI ils ont prévu un truc pour dire de combien la pile va devoir diminuer lorsqu'on sort du bloc.
Pour des variables comme les tableaux de taille dynamique du c99, il n'y a pas d'autres moyens que de "bouger" la pile en plein milieu de l'exécution de la fonction... Mais je ne pensais pas que cela soit fait dans d'autres cas.
Je pense que tu as mal lu les précédents commentaires.Citation:
Envoyé par valefor
Tu fais référence aux ressources mémoire ?
Je me posais la question en terme de temps. Combien de temps cela prend d'augmenter la taille de la pile... mais réflexion faite, c'est négligeable (c'est juste incrémenter un registre, il n'y a rien besoin de stoker d'autre sur la pile).
Bon, du coup j’admets que ce n'est pas un si gros soucis que la pile joue au yoyo au sein même d'une fonction...
Toutes ces histoires de taille de pile qui change en cours d'exécution d'une fonction me font penser à un post parallèle sur les goto :)
En gros, niveau machine, déplacer la pile, pour celle ci, ce n'est pas une masse à faire.
Donc je pense que le topic est résolu (avant qu'on m'avertisse encore une fois:?)
merci à tous pour vos réponses :ccool: