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
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:
Oups ! Au passage, ça explique pourquoi l'optimiseur arrivait à faire du code aussi rapide ...
-- Matthieu
Pierre Maurette <maurette.pierre@free.fr> writes:
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:
Oups ! Au passage, ça explique pourquoi l'optimiseur arrivait à faire
du code aussi rapide ...
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:
Oups ! Au passage, ça explique pourquoi l'optimiseur arrivait à faire du code aussi rapide ...
-- Matthieu
kanze
Pierre Maurette wrote in message news:...
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.
Main renvoie toujours légalement un int. (Quand il retourne. On peut très bien concevoir des programmes où main ne retourne jamais.) Et moi aussi, je le trouve de très mauvais style de l'omettre.
Mais > peu importe...
Celui qui me génait, c'est celui de f() dans:
À toi aussi:-).
<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).
La norme prévoit le cas général, où la valeur de retour pourrait aussi avoir un type avec un destructeur ou des constructeurs non triviaux. Elle prévoit aussi des implémentations sur des architectures « bizarre », où peut-être il faut allouer de l'espace pour la valeur de retour (même int) d'une façon particulière. Sur une implémentation courante, sur une architecture habituelle, la seule chose que tu risques, c'est effectivement une valeur indéfinie. Pour un int -- pour d'autres types, tu pourrais bien avoir des comportements particuliers (core dump, etc.).
En revanche, ce qui se passe ici, c'est que le code n'utilise jamais la valeur calculée dans x. Et que c'est rélativement facile au compilateur de le detecter, et de supprimer complétement tout le contenu de la fonction. Ce qui pourrait expliquer pourquoi la version optimisée est tellement plus rapide que la version non optimisée.
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.
Tout à fait.
Chez moi, deux compilateurs sur trois acceptent le code.
Pourquoi pas ? C'est légal, à condition de ne jamais appeler la fonction.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<i1pt70tf2i9hpg0u7mrqv8ocbcc3qu4ptu@4ax.com>...
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.
Main renvoie toujours légalement un int. (Quand il retourne. On peut
très bien concevoir des programmes où main ne retourne jamais.) Et moi
aussi, je le trouve de très mauvais style de l'omettre.
Mais > peu importe...
Celui qui me génait, c'est celui de f() dans:
À toi aussi:-).
<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).
La norme prévoit le cas général, où la valeur de retour pourrait aussi
avoir un type avec un destructeur ou des constructeurs non
triviaux. Elle prévoit aussi des implémentations sur des architectures
« bizarre », où peut-être il faut allouer de l'espace pour la valeur de
retour (même int) d'une façon particulière. Sur une implémentation
courante, sur une architecture habituelle, la seule chose que tu
risques, c'est effectivement une valeur indéfinie. Pour un int -- pour
d'autres types, tu pourrais bien avoir des comportements particuliers
(core dump, etc.).
En revanche, ce qui se passe ici, c'est que le code n'utilise jamais la
valeur calculée dans x. Et que c'est rélativement facile au compilateur
de le detecter, et de supprimer complétement tout le contenu de la
fonction. Ce qui pourrait expliquer pourquoi la version optimisée est
tellement plus rapide que la version non optimisée.
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.
Tout à fait.
Chez moi, deux compilateurs sur trois acceptent le code.
Pourquoi pas ? C'est légal, à condition de ne jamais appeler la
fonction.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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.
Main renvoie toujours légalement un int. (Quand il retourne. On peut très bien concevoir des programmes où main ne retourne jamais.) Et moi aussi, je le trouve de très mauvais style de l'omettre.
Mais > peu importe...
Celui qui me génait, c'est celui de f() dans:
À toi aussi:-).
<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).
La norme prévoit le cas général, où la valeur de retour pourrait aussi avoir un type avec un destructeur ou des constructeurs non triviaux. Elle prévoit aussi des implémentations sur des architectures « bizarre », où peut-être il faut allouer de l'espace pour la valeur de retour (même int) d'une façon particulière. Sur une implémentation courante, sur une architecture habituelle, la seule chose que tu risques, c'est effectivement une valeur indéfinie. Pour un int -- pour d'autres types, tu pourrais bien avoir des comportements particuliers (core dump, etc.).
En revanche, ce qui se passe ici, c'est que le code n'utilise jamais la valeur calculée dans x. Et que c'est rélativement facile au compilateur de le detecter, et de supprimer complétement tout le contenu de la fonction. Ce qui pourrait expliquer pourquoi la version optimisée est tellement plus rapide que la version non optimisée.
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.
Tout à fait.
Chez moi, deux compilateurs sur trois acceptent le code.
Pourquoi pas ? C'est légal, à condition de ne jamais appeler la fonction.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alexandre
"Hamiral" a écrit dans le message de news:
<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
oopss.... mille excuses à tous, et principalement à Maitre Capello Himself ;-) quand je pense que je passe une partie de mes cours à râler après mes étudiants à cause de leurs fautes d'orthographe... J'espère qu'ils ne fréquentent pas ce forum ;-)
"Hamiral" <Hamiral@hamham.fr> a écrit dans le message de
news:pan.2004.04.15.18.55.41.351781@hamham.fr...
<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
oopss.... mille excuses à tous, et principalement à Maitre Capello Himself
;-)
quand je pense que je passe une partie de mes cours à râler après mes
étudiants à cause de leurs fautes d'orthographe... J'espère qu'ils ne
fréquentent pas ce forum ;-)
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
oopss.... mille excuses à tous, et principalement à Maitre Capello Himself ;-) quand je pense que je passe une partie de mes cours à râler après mes étudiants à cause de leurs fautes d'orthographe... J'espère qu'ils ne fréquentent pas ce forum ;-)
Fabien LE LEZ
On Fri, 16 Apr 2004 19:42:12 +0200, "Alexandre" wrote:
surtout que <mode citation on> Une optimisation précose est la source de tous les mots <mode citation off>
oopss.... mille excuses à tous, et principalement à Maitre Capello Himself
Tu me déçois, là. T'aurais quand même pu trouver une pirouette pour t'en sortir, au lieu de bêtement avouer que tu as fait une faute d'orthographe...
-- ;-) FLL, Epagneul Breton
On Fri, 16 Apr 2004 19:42:12 +0200, "Alexandre"
<alex.g@netcourrier.com> wrote:
surtout que <mode citation on> Une optimisation précose est la source de
tous les mots <mode citation off>
oopss.... mille excuses à tous, et principalement à Maitre Capello Himself
Tu me déçois, là. T'aurais quand même pu trouver une pirouette pour
t'en sortir, au lieu de bêtement avouer que tu as fait une faute
d'orthographe...
