Bonjour,
je me pose une question qu'est ce qui est le + interressant de faire en
termes d'occupation memoire.
Si j'ai une fonction qui utilise une var locale, cette fonction-membre
est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var
locale en attribut???
est ce que ça apporte quelque chose de grapiller de l'espace memoire en
termes de vitesse d'execution de cette fonction??
merci
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut???
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct.
Donc, à priori, la variable locale ira plus vite.
-- Matthieu
Chat <chat@nospam.com> writes:
Bonjour,
je me pose une question qu'est ce qui est le + interressant de faire
en termes d'occupation memoire.
Si j'ai une fonction qui utilise une var locale, cette fonction-membre
est appellée assez frequemment, ne vaut mieux t'il pas mettre cette
var locale en attribut???
L'objet est passé par référence à la fonction membre, donc, pour
accéder à un attribut, il faut un indirection de pointeur, alors que
pour une variable locale, c'est un accès direct.
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut???
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct.
Donc, à priori, la variable locale ira plus vite.
-- Matthieu
Jean-Marc Bourguet
Chat writes:
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut??? est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction??
La variable locale est a priori plus rapide et utilise de la memoire de facon moins permanente. La passer en membre n'a donc de sens que si son initialisation est couteuse et peut alors etre evitee.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Chat <chat@nospam.com> writes:
Bonjour,
je me pose une question qu'est ce qui est le + interressant de faire en
termes d'occupation memoire.
Si j'ai une fonction qui utilise une var locale, cette fonction-membre est
appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale
en attribut???
est ce que ça apporte quelque chose de grapiller de l'espace memoire en
termes de vitesse d'execution de cette fonction??
La variable locale est a priori plus rapide et utilise de la memoire
de facon moins permanente. La passer en membre n'a donc de sens que
si son initialisation est couteuse et peut alors etre evitee.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut??? est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction??
La variable locale est a priori plus rapide et utilise de la memoire de facon moins permanente. La passer en membre n'a donc de sens que si son initialisation est couteuse et peut alors etre evitee.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pierre Maurette
Chat typa:
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut??? Je ne pense pas.
Un détail: attribut ou variable locale statique, la place occupée par la variable est la même. Pour une variable locale auto, cette taille peut être zéro. Le code devrait occuper un peu plus de place dans le cas d'un attribut. Une vraie variable locale (auto, non statique, non volatile) ne sera souvent tout simplement pas créée en mémoire. Donc, gain sur tous les plans. Laissez le compilateur optimiser à sa guise. Ce que je ne sais pas, c'est si le compilateur peut optimiser grave, au point de détecter qu'un attribut (private, of course) n'est utilisé que dans une seule fonction membre et optimiser en connséquence. Je pense que non. De plus, bien que ce ne soit pas votre question, il est certainement préférable de respecter le "sens". Et transformer une vrai variable locale en attribut n'est pas naturel du tout. Dans le cas d'une variable locale statique, la question peut se poser. L'avantage est à la variable locale, puisque son adresse est codée en constante, celle de l'attribut en this + constante. La différence ne doit pas être significative, personellement, je mettrais en attribut si la variable a un sens pour la classe.
est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction?? Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
Pierre
Chat <chat@nospam.com> typa:
Bonjour,
je me pose une question qu'est ce qui est le + interressant de faire en
termes d'occupation memoire.
Si j'ai une fonction qui utilise une var locale, cette fonction-membre
est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var
locale en attribut???
Je ne pense pas.
Un détail: attribut ou variable locale statique, la place occupée par
la variable est la même. Pour une variable locale auto, cette taille
peut être zéro. Le code devrait occuper un peu plus de place dans le
cas d'un attribut.
Une vraie variable locale (auto, non statique, non volatile) ne sera
souvent tout simplement pas créée en mémoire. Donc, gain sur tous les
plans. Laissez le compilateur optimiser à sa guise. Ce que je ne sais
pas, c'est si le compilateur peut optimiser grave, au point de
détecter qu'un attribut (private, of course) n'est utilisé que dans
une seule fonction membre et optimiser en connséquence. Je pense que
non.
De plus, bien que ce ne soit pas votre question, il est certainement
préférable de respecter le "sens".
Et transformer une vrai variable locale en attribut n'est pas naturel
du tout.
Dans le cas d'une variable locale statique, la question peut se poser.
L'avantage est à la variable locale, puisque son adresse est codée en
constante, celle de l'attribut en this + constante. La différence ne
doit pas être significative, personellement, je mettrais en attribut
si la variable a un sens pour la classe.
est ce que ça apporte quelque chose de grapiller de l'espace memoire en
termes de vitesse d'execution de cette fonction??
Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut??? Je ne pense pas.
Un détail: attribut ou variable locale statique, la place occupée par la variable est la même. Pour une variable locale auto, cette taille peut être zéro. Le code devrait occuper un peu plus de place dans le cas d'un attribut. Une vraie variable locale (auto, non statique, non volatile) ne sera souvent tout simplement pas créée en mémoire. Donc, gain sur tous les plans. Laissez le compilateur optimiser à sa guise. Ce que je ne sais pas, c'est si le compilateur peut optimiser grave, au point de détecter qu'un attribut (private, of course) n'est utilisé que dans une seule fonction membre et optimiser en connséquence. Je pense que non. De plus, bien que ce ne soit pas votre question, il est certainement préférable de respecter le "sens". Et transformer une vrai variable locale en attribut n'est pas naturel du tout. Dans le cas d'une variable locale statique, la question peut se poser. L'avantage est à la variable locale, puisque son adresse est codée en constante, celle de l'attribut en this + constante. La différence ne doit pas être significative, personellement, je mettrais en attribut si la variable a un sens pour la classe.
est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction?? Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
Pierre
Pierre Maurette
Matthieu Moy typa:
Chat writes:
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut???
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct. Pour une statique. Pour une auto, soit elle n'existe pas en mémoire,
soit elle est réellement créée, dans la pile par exemple (selon l'implémentation), ce qui correspond à une indirection. Mais je pense que en termes de vitesse, ça doit être kif kif.
Bonjour,
je me pose une question qu'est ce qui est le + interressant de faire
en termes d'occupation memoire.
Si j'ai une fonction qui utilise une var locale, cette fonction-membre
est appellée assez frequemment, ne vaut mieux t'il pas mettre cette
var locale en attribut???
L'objet est passé par référence à la fonction membre, donc, pour
accéder à un attribut, il faut un indirection de pointeur, alors que
pour une variable locale, c'est un accès direct.
Pour une statique. Pour une auto, soit elle n'existe pas en mémoire,
soit elle est réellement créée, dans la pile par exemple (selon
l'implémentation), ce qui correspond à une indirection. Mais je pense
que en termes de vitesse, ça doit être kif kif.
Bonjour, je me pose une question qu'est ce qui est le + interressant de faire en termes d'occupation memoire. Si j'ai une fonction qui utilise une var locale, cette fonction-membre est appellée assez frequemment, ne vaut mieux t'il pas mettre cette var locale en attribut???
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct. Pour une statique. Pour une auto, soit elle n'existe pas en mémoire,
soit elle est réellement créée, dans la pile par exemple (selon l'implémentation), ce qui correspond à une indirection. Mais je pense que en termes de vitesse, ça doit être kif kif.
Pierre
Matthieu Moy
Pierre Maurette writes:
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct.
Pour une statique. Pour une auto, soit elle n'existe pas en mémoire, soit elle est réellement créée, dans la pile par exemple (selon l'implémentation), ce qui correspond à une indirection.
Oui, mais si tu comptes l'indirection par rapport au pointeur de pile, dans le cas d'un attribut, il y a /deux/ indirections : Récupérer la valeur du pointeur vers l'objet sur la pile, puis accéder à l'objet.
Mais je pense que en termes de vitesse, ça doit être kif kif.
Petit benchmark à l'appui, la variable locale est un peu plus rapide avec g++, mais sur mon exemple, les deux sont équivalentes avec "g++ -O3". (Et d'ailleurs, je suis impressionné : il y a un facteur prèsque 20 entre la version optimisée et la version non optimisée !!)
#include <iostream>
struct A { int f(int y) { int x; // On peut le mettre en attribut pour comparer. x = y + 1; x = x * x; x = x + y; } };
int main() { int res = 0; A a; for (int i = 0; i <= 100000000; i++) { res += a.f(i%10) % 1000; } std::cout << "res = " << res << std::endl; }
Bref, si la variable est locale conceptuellement, aucune raison de la passer en attribut.
-- Matthieu
Pierre Maurette <maurette.pierre@free.fr> writes:
L'objet est passé par référence à la fonction membre, donc, pour
accéder à un attribut, il faut un indirection de pointeur, alors que
pour une variable locale, c'est un accès direct.
Pour une statique. Pour une auto, soit elle n'existe pas en mémoire,
soit elle est réellement créée, dans la pile par exemple (selon
l'implémentation), ce qui correspond à une indirection.
Oui, mais si tu comptes l'indirection par rapport au pointeur de pile,
dans le cas d'un attribut, il y a /deux/ indirections : Récupérer la
valeur du pointeur vers l'objet sur la pile, puis accéder à l'objet.
Mais je pense que en termes de vitesse, ça doit être kif kif.
Petit benchmark à l'appui, la variable locale est un peu plus rapide
avec g++, mais sur mon exemple, les deux sont équivalentes avec "g++
-O3". (Et d'ailleurs, je suis impressionné : il y a un facteur prèsque
20 entre la version optimisée et la version non optimisée !!)
#include <iostream>
struct A {
int f(int y) {
int x; // On peut le mettre en attribut pour comparer.
x = y + 1;
x = x * x;
x = x + y;
}
};
int main() {
int res = 0;
A a;
for (int i = 0; i <= 100000000; i++) {
res += a.f(i%10) % 1000;
}
std::cout << "res = " << res << std::endl;
}
Bref, si la variable est locale conceptuellement, aucune raison de la
passer en attribut.
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct.
Pour une statique. Pour une auto, soit elle n'existe pas en mémoire, soit elle est réellement créée, dans la pile par exemple (selon l'implémentation), ce qui correspond à une indirection.
Oui, mais si tu comptes l'indirection par rapport au pointeur de pile, dans le cas d'un attribut, il y a /deux/ indirections : Récupérer la valeur du pointeur vers l'objet sur la pile, puis accéder à l'objet.
Mais je pense que en termes de vitesse, ça doit être kif kif.
Petit benchmark à l'appui, la variable locale est un peu plus rapide avec g++, mais sur mon exemple, les deux sont équivalentes avec "g++ -O3". (Et d'ailleurs, je suis impressionné : il y a un facteur prèsque 20 entre la version optimisée et la version non optimisée !!)
#include <iostream>
struct A { int f(int y) { int x; // On peut le mettre en attribut pour comparer. x = y + 1; x = x * x; x = x + y; } };
int main() { int res = 0; A a; for (int i = 0; i <= 100000000; i++) { res += a.f(i%10) % 1000; } std::cout << "res = " << res << std::endl; }
Bref, si la variable est locale conceptuellement, aucune raison de la passer en attribut.
-- Matthieu
Pierre Maurette
Matthieu Moy typa:
Pierre Maurette writes:
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct.
Pour une statique. Pour une auto, soit elle n'existe pas en mémoire, soit elle est réellement créée, dans la pile par exemple (selon l'implémentation), ce qui correspond à une indirection.
Oui, mais si tu comptes l'indirection par rapport au pointeur de pile, dans le cas d'un attribut, il y a /deux/ indirections : Récupérer la valeur du pointeur vers l'objet sur la pile, puis accéder à l'objet. Oui da.
Mais je pense que en termes de vitesse, ça doit être kif kif.
Petit benchmark à l'appui, la variable locale est un peu plus rapide avec g++, mais sur mon exemple, les deux sont équivalentes avec "g++ -O3". (Et d'ailleurs, je suis impressionné : il y a un facteur prèsque 20 entre la version optimisée et la version non optimisée !!)
#include <iostream>
struct A { int f(int y) { int x; // On peut le mettre en attribut pour comparer. x = y + 1; x = x * x; x = x + y; } };
int main() { int res = 0; A a; for (int i = 0; i <= 100000000; i++) { res += a.f(i%10) % 1000; } std::cout << "res = " << res << std::endl; } Pas de return ?
Bref, si la variable est locale conceptuellement, aucune raison de la passer en attribut. Je pense que c'est la morale principale de l'histoire.
Et puis un attribut n'est pas une variable locale. Un attribut "normal" est statique par rapport à l'instance, un attribut static est statique par rapport à la classe, une variable locale static est statique par rapport à la classe (dites-moi si je me trompe), et une variable locale auto est ... une variable locale auto.
L'objet est passé par référence à la fonction membre, donc, pour
accéder à un attribut, il faut un indirection de pointeur, alors que
pour une variable locale, c'est un accès direct.
Pour une statique. Pour une auto, soit elle n'existe pas en mémoire,
soit elle est réellement créée, dans la pile par exemple (selon
l'implémentation), ce qui correspond à une indirection.
Oui, mais si tu comptes l'indirection par rapport au pointeur de pile,
dans le cas d'un attribut, il y a /deux/ indirections : Récupérer la
valeur du pointeur vers l'objet sur la pile, puis accéder à l'objet.
Oui da.
Mais je pense que en termes de vitesse, ça doit être kif kif.
Petit benchmark à l'appui, la variable locale est un peu plus rapide
avec g++, mais sur mon exemple, les deux sont équivalentes avec "g++
-O3". (Et d'ailleurs, je suis impressionné : il y a un facteur prèsque
20 entre la version optimisée et la version non optimisée !!)
#include <iostream>
struct A {
int f(int y) {
int x; // On peut le mettre en attribut pour comparer.
x = y + 1;
x = x * x;
x = x + y;
}
};
int main() {
int res = 0;
A a;
for (int i = 0; i <= 100000000; i++) {
res += a.f(i%10) % 1000;
}
std::cout << "res = " << res << std::endl;
}
Pas de return ?
Bref, si la variable est locale conceptuellement, aucune raison de la
passer en attribut.
Je pense que c'est la morale principale de l'histoire.
Et puis un attribut n'est pas une variable locale.
Un attribut "normal" est statique par rapport à l'instance, un
attribut static est statique par rapport à la classe, une variable
locale static est statique par rapport à la classe (dites-moi si je me
trompe), et une variable locale auto est ... une variable locale auto.
L'objet est passé par référence à la fonction membre, donc, pour accéder à un attribut, il faut un indirection de pointeur, alors que pour une variable locale, c'est un accès direct.
Pour une statique. Pour une auto, soit elle n'existe pas en mémoire, soit elle est réellement créée, dans la pile par exemple (selon l'implémentation), ce qui correspond à une indirection.
Oui, mais si tu comptes l'indirection par rapport au pointeur de pile, dans le cas d'un attribut, il y a /deux/ indirections : Récupérer la valeur du pointeur vers l'objet sur la pile, puis accéder à l'objet. Oui da.
Mais je pense que en termes de vitesse, ça doit être kif kif.
Petit benchmark à l'appui, la variable locale est un peu plus rapide avec g++, mais sur mon exemple, les deux sont équivalentes avec "g++ -O3". (Et d'ailleurs, je suis impressionné : il y a un facteur prèsque 20 entre la version optimisée et la version non optimisée !!)
#include <iostream>
struct A { int f(int y) { int x; // On peut le mettre en attribut pour comparer. x = y + 1; x = x * x; x = x + y; } };
int main() { int res = 0; A a; for (int i = 0; i <= 100000000; i++) { res += a.f(i%10) % 1000; } std::cout << "res = " << res << std::endl; } Pas de return ?
Bref, si la variable est locale conceptuellement, aucune raison de la passer en attribut. Je pense que c'est la morale principale de l'histoire.
Et puis un attribut n'est pas une variable locale. Un attribut "normal" est statique par rapport à l'instance, un attribut static est statique par rapport à la classe, une variable locale static est statique par rapport à la classe (dites-moi si je me trompe), et une variable locale auto est ... une variable locale auto.
Pierre
Fabien LE LEZ
On Thu, 15 Apr 2004 15:00:53 +0200, Pierre Maurette wrote:
int main() {
Pas de return ?
Non, le return dans main() est implicite.
-- ;-) FLL, Epagneul Breton
On Thu, 15 Apr 2004 15:00:53 +0200, Pierre Maurette
<maurette.pierre@free.fr> wrote:
On Thu, 15 Apr 2004 15:00:53 +0200, Pierre Maurette wrote:
int main() {
Pas de return ?
Non, le return dans main() est implicite.
-- ;-) FLL, Epagneul Breton
Alexandre
<snip>
est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction?? Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
surtout que <mode citation on> Une optimisation précose est la source de tous les mots <mode citation off>
D'accord avec vous, un attribut doit être dans une classe s'il a un sens, point barre. L'exemple type, pour moi, parce que je me bagarre souvent avec mes étudiants à cause de ça, c'est une classe utilisant un std::list, ou une classe implémentant une structure de ce type : mets-on dedans un itérateur, un pointeur "courant" ou qq chose que ça soit, parce que toutes les méthodes parcourant la liste en ont besoin ? Non, on met une variable locale, pour plusieurs raisons : - un itérateur sur liste n'a de sens que pour les méthodes parcourant la liste, pas pour la liste elle-même - une instance constante ne pourra pas être parcourue (le curseur est constant), pénible pour les passages par réf - une instance n'utilisant pas de parcours (copie temporaire, par ex) "gaspille" un attribut (donc de l'espace) pour rien
<snip>
est ce que ça apporte quelque chose de grapiller de l'espace memoire en
termes de vitesse d'execution de cette fonction??
Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
surtout que <mode citation on> Une optimisation précose est la source de
tous les mots <mode citation off>
D'accord avec vous, un attribut doit être dans une classe s'il a un sens,
point barre. L'exemple type, pour moi, parce que je me bagarre souvent avec
mes étudiants à cause de ça, c'est une classe utilisant un std::list, ou une
classe implémentant une structure de ce type : mets-on dedans un itérateur,
un pointeur "courant" ou qq chose que ça soit, parce que toutes les méthodes
parcourant la liste en ont besoin ? Non, on met une variable locale, pour
plusieurs raisons :
- un itérateur sur liste n'a de sens que pour les méthodes parcourant la
liste, pas pour la liste elle-même
- une instance constante ne pourra pas être parcourue (le curseur est
constant), pénible pour les passages par réf
- une instance n'utilisant pas de parcours (copie temporaire, par ex)
"gaspille" un attribut (donc de l'espace) pour rien
est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction?? Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
surtout que <mode citation on> Une optimisation précose est la source de tous les mots <mode citation off>
D'accord avec vous, un attribut doit être dans une classe s'il a un sens, point barre. L'exemple type, pour moi, parce que je me bagarre souvent avec mes étudiants à cause de ça, c'est une classe utilisant un std::list, ou une classe implémentant une structure de ce type : mets-on dedans un itérateur, un pointeur "courant" ou qq chose que ça soit, parce que toutes les méthodes parcourant la liste en ont besoin ? Non, on met une variable locale, pour plusieurs raisons : - un itérateur sur liste n'a de sens que pour les méthodes parcourant la liste, pas pour la liste elle-même - une instance constante ne pourra pas être parcourue (le curseur est constant), pénible pour les passages par réf - une instance n'utilisant pas de parcours (copie temporaire, par ex) "gaspille" un attribut (donc de l'espace) pour rien
Hamiral
Le Thu, 15 Apr 2004 20:23:54 +0200, Alexandre a écrit :
<snip>
est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction?? Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
surtout que <mode citation on> Une optimisation précose est la source de tous les mots <mode citation off>
<mode capello on> maux, pas mots<mode capello off>
désolé :)
-- Hamiral
Le Thu, 15 Apr 2004 20:23:54 +0200, Alexandre a écrit :
<snip>
est ce que ça apporte quelque chose de grapiller de l'espace memoire en
termes de vitesse d'execution de cette fonction??
Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
surtout que <mode citation on> Une optimisation précose est la source de
tous les mots <mode citation off>
<mode capello on> maux, pas mots<mode capello off>
Le Thu, 15 Apr 2004 20:23:54 +0200, Alexandre a écrit :
<snip>
est ce que ça apporte quelque chose de grapiller de l'espace memoire en termes de vitesse d'execution de cette fonction?? Du dérisoire, je suppose. Opinion personnelle déjà donnée, coder selon
la sémantique et laisser popol optimiser.
surtout que <mode citation on> Une optimisation précose est la source de tous les mots <mode citation off>
<mode capello on> maux, pas mots<mode capello off>
désolé :)
-- Hamiral
Pierre Maurette
Fabien LE LEZ typa:
On Thu, 15 Apr 2004 15:00:53 +0200, Pierre Maurette wrote:
int main() {
Pas de return ?
Non, le return dans main() est implicite. Tiens, y'avait aussi celui-là. Je préfère mettre un return, dans tous
les cas mais surtout quand main() renvoie "légalement" un int. Mais peu importe... Celui qui me génait, c'est celui de f() dans: <code> struct A { int f(int y) { int x; // On peut le mettre en attribut pour comparer. x = y + 1; x = x * x; x = x + y; } }; </code>
La norme ($6.6.3) parle clairement d'un "undefined behavior in a value-returning function". C'est même plus grave que ce à quoi je m'attendais (une undefined valeur de retour). En fait, si la fonction retourne dans un registre, pas trop de problème. Le "undefined behavior" concerne peut-être les cas où la fonction retournerait dans la pile -> déséquilibre d'icelle. Chez moi, deux compilateurs sur trois acceptent le code. Pierre
Fabien LE LEZ <gramster@gramster.com> typa:
On Thu, 15 Apr 2004 15:00:53 +0200, Pierre Maurette
<maurette.pierre@free.fr> wrote:
int main() {
Pas de return ?
Non, le return dans main() est implicite.
Tiens, y'avait aussi celui-là. Je préfère mettre un return, dans tous
les cas mais surtout quand main() renvoie "légalement" un int. Mais
peu importe...
Celui qui me génait, c'est celui de f() dans:
<code>
struct A {
int f(int y) {
int x; // On peut le mettre en attribut pour comparer.
x = y + 1;
x = x * x;
x = x + y;
}
};
</code>
La norme ($6.6.3) parle clairement d'un "undefined behavior in a
value-returning function".
C'est même plus grave que ce à quoi je m'attendais (une undefined
valeur de retour).
En fait, si la fonction retourne dans un registre, pas trop de
problème. Le "undefined behavior" concerne peut-être les cas où la
fonction retournerait dans la pile -> déséquilibre d'icelle.
Chez moi, deux compilateurs sur trois acceptent le code.
Pierre
On Thu, 15 Apr 2004 15:00:53 +0200, Pierre Maurette wrote:
int main() {
Pas de return ?
Non, le return dans main() est implicite. Tiens, y'avait aussi celui-là. Je préfère mettre un return, dans tous
les cas mais surtout quand main() renvoie "légalement" un int. Mais peu importe... Celui qui me génait, c'est celui de f() dans: <code> struct A { int f(int y) { int x; // On peut le mettre en attribut pour comparer. x = y + 1; x = x * x; x = x + y; } }; </code>
La norme ($6.6.3) parle clairement d'un "undefined behavior in a value-returning function". C'est même plus grave que ce à quoi je m'attendais (une undefined valeur de retour). En fait, si la fonction retourne dans un registre, pas trop de problème. Le "undefined behavior" concerne peut-être les cas où la fonction retournerait dans la pile -> déséquilibre d'icelle. Chez moi, deux compilateurs sur trois acceptent le code. Pierre
