boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
{
...
}
est-ce que 5+toto est évalué à chaque boucle, ou le compilateur est
assez malin pour faire l'évaluation au debut et stocker le resultat
dans une variable temporaire ?
boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
{
...
}
est-ce que 5+toto est évalué à chaque boucle, ou le compilateur est
assez malin pour faire l'évaluation au debut et stocker le resultat
dans une variable temporaire ?
boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
{
...
}
est-ce que 5+toto est évalué à chaque boucle, ou le compilateur est
assez malin pour faire l'évaluation au debut et stocker le resultat
dans une variable temporaire ?
PurL writes:boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait evaluee a chaque
fois. Mais l'optimisation qui consiste a sortir des expressions
constantes d'une boucle est un grand classique. Reste a t'assurer que
l'optimiseur peut detecter que l'expression est constante.
PurL <purl@9entoutelettre.fr> writes:
boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait evaluee a chaque
fois. Mais l'optimisation qui consiste a sortir des expressions
constantes d'une boucle est un grand classique. Reste a t'assurer que
l'optimiseur peut detecter que l'expression est constante.
PurL writes:boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait evaluee a chaque
fois. Mais l'optimisation qui consiste a sortir des expressions
constantes d'une boucle est un grand classique. Reste a t'assurer que
l'optimiseur peut detecter que l'expression est constante.
boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
{
...
}
est-ce que 5+toto est évalué à chaque boucle, ou le compilateur est assez
malin pour faire l'évaluation au debut et stocker le resultat dans une
variable temporaire ?
Un bon compilateur devrait toujours le faire dans les cas exigés par le
boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
{
...
}
est-ce que 5+toto est évalué à chaque boucle, ou le compilateur est assez
malin pour faire l'évaluation au debut et stocker le resultat dans une
variable temporaire ?
Un bon compilateur devrait toujours le faire dans les cas exigés par le
boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
{
...
}
est-ce que 5+toto est évalué à chaque boucle, ou le compilateur est assez
malin pour faire l'évaluation au debut et stocker le resultat dans une
variable temporaire ?
Un bon compilateur devrait toujours le faire dans les cas exigés par le
Si on imagine le fichier suivant :
int toto;
void modifToto(int n) {
toto = n;
}
void foo() {
for (int i = 0; i < 500000/toto; i++) {
cout << i << endl;
}
est-ce que les compilos usuels évalueraient 500000/toto
une seule fois, ou pas (et alors, c'est en prévision de
possibles threads, ou pour d'autres raisons ?)
Si on imagine le fichier suivant :
int toto;
void modifToto(int n) {
toto = n;
}
void foo() {
for (int i = 0; i < 500000/toto; i++) {
cout << i << endl;
}
est-ce que les compilos usuels évalueraient 500000/toto
une seule fois, ou pas (et alors, c'est en prévision de
possibles threads, ou pour d'autres raisons ?)
Si on imagine le fichier suivant :
int toto;
void modifToto(int n) {
toto = n;
}
void foo() {
for (int i = 0; i < 500000/toto; i++) {
cout << i << endl;
}
est-ce que les compilos usuels évalueraient 500000/toto
une seule fois, ou pas (et alors, c'est en prévision de
possibles threads, ou pour d'autres raisons ?)
(02 May 2005 15:29,
) a
PurL writes:boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait evaluee a
chaque
fois. Mais l'optimisation qui consiste a sortir des expressions
constantes d'une boucle est un grand classique. Reste a t'assurer
que
l'optimiseur peut detecter que l'expression est constante.
est-ce que le compilateur doit se soucier d'éventuelles
modifications de
toto par d'éventuels autres threads ? comme la norme ne connait rien
des
threads, je considère que le compilo a le droit d'analyser le code
dans le
modèle 'standard' de flot d'éxécution (mono-thread). Mais dans la
pratique ?
jm@bourguet.org (02 May 2005 15:29,
<pxbmzrd3gdo.fsf@news.bourguet.org>) a
PurL <purl@9entoutelettre.fr> writes:
boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait evaluee a
chaque
fois. Mais l'optimisation qui consiste a sortir des expressions
constantes d'une boucle est un grand classique. Reste a t'assurer
que
l'optimiseur peut detecter que l'expression est constante.
est-ce que le compilateur doit se soucier d'éventuelles
modifications de
toto par d'éventuels autres threads ? comme la norme ne connait rien
des
threads, je considère que le compilo a le droit d'analyser le code
dans le
modèle 'standard' de flot d'éxécution (mono-thread). Mais dans la
pratique ?
(02 May 2005 15:29,
) a
PurL writes:boujour,
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait evaluee a
chaque
fois. Mais l'optimisation qui consiste a sortir des expressions
constantes d'une boucle est un grand classique. Reste a t'assurer
que
l'optimiseur peut detecter que l'expression est constante.
est-ce que le compilateur doit se soucier d'éventuelles
modifications de
toto par d'éventuels autres threads ? comme la norme ne connait rien
des
threads, je considère que le compilo a le droit d'analyser le code
dans le
modèle 'standard' de flot d'éxécution (mono-thread). Mais dans la
pratique ?
(02 May 2005 15:29,PurL writes:Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait
evaluee a chaque fois. Mais l'optimisation qui consiste a
sortir des expressions constantes d'une boucle est un grand
classique. Reste a t'assurer que l'optimiseur peut detecter
que l'expression est constante.
est-ce que le compilateur doit se soucier d'éventuelles
modifications de toto par d'éventuels autres threads ? comme
la norme ne connait rien des threads, je considère que le
compilo a le droit d'analyser le code dans le modèle
'standard' de flot d'éxécution (mono-thread). Mais dans la
pratique ?
Si on imagine le fichier suivant :
int toto;
void modifToto(int n) {
toto = n;
}
void foo() {
for (int i = 0; i < 500000/toto; i++) {
cout << i << endl;
}
est-ce que les compilos usuels évalueraient 500000/toto une
seule fois, ou pas (et alors, c'est en prévision de possibles
threads, ou pour d'autres raisons ?)
jm@bourguet.org (02 May 2005 15:29,
PurL <purl@9entoutelettre.fr> writes:
Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait
evaluee a chaque fois. Mais l'optimisation qui consiste a
sortir des expressions constantes d'une boucle est un grand
classique. Reste a t'assurer que l'optimiseur peut detecter
que l'expression est constante.
est-ce que le compilateur doit se soucier d'éventuelles
modifications de toto par d'éventuels autres threads ? comme
la norme ne connait rien des threads, je considère que le
compilo a le droit d'analyser le code dans le modèle
'standard' de flot d'éxécution (mono-thread). Mais dans la
pratique ?
Si on imagine le fichier suivant :
int toto;
void modifToto(int n) {
toto = n;
}
void foo() {
for (int i = 0; i < 500000/toto; i++) {
cout << i << endl;
}
est-ce que les compilos usuels évalueraient 500000/toto une
seule fois, ou pas (et alors, c'est en prévision de possibles
threads, ou pour d'autres raisons ?)
(02 May 2005 15:29,PurL writes:Dans une boucle for comme celle ci :
for (int i = 0; i < 5 + toto; i++)
Le comportement doit etre comme si l'expression etait
evaluee a chaque fois. Mais l'optimisation qui consiste a
sortir des expressions constantes d'une boucle est un grand
classique. Reste a t'assurer que l'optimiseur peut detecter
que l'expression est constante.
est-ce que le compilateur doit se soucier d'éventuelles
modifications de toto par d'éventuels autres threads ? comme
la norme ne connait rien des threads, je considère que le
compilo a le droit d'analyser le code dans le modèle
'standard' de flot d'éxécution (mono-thread). Mais dans la
pratique ?
Si on imagine le fichier suivant :
int toto;
void modifToto(int n) {
toto = n;
}
void foo() {
for (int i = 0; i < 500000/toto; i++) {
cout << i << endl;
}
est-ce que les compilos usuels évalueraient 500000/toto une
seule fois, ou pas (et alors, c'est en prévision de possibles
threads, ou pour d'autres raisons ?)
En général : dès que l'expression contient une variable globale,
ou une variable dont on a pris l'adresse (y compris en forme de
référence), et que la boucle contient le moindre appel à une
fonction dont le compilateur ne voit pas l'implémentation, le
compilateur est obligé à supposer que cette fonction change la
valeur de la variable.
http://minilien.com/?sQNnEIKr4V
En général : dès que l'expression contient une variable globale,
ou une variable dont on a pris l'adresse (y compris en forme de
référence), et que la boucle contient le moindre appel à une
fonction dont le compilateur ne voit pas l'implémentation, le
compilateur est obligé à supposer que cette fonction change la
valeur de la variable.
http://minilien.com/?sQNnEIKr4V
En général : dès que l'expression contient une variable globale,
ou une variable dont on a pris l'adresse (y compris en forme de
référence), et que la boucle contient le moindre appel à une
fonction dont le compilateur ne voit pas l'implémentation, le
compilateur est obligé à supposer que cette fonction change la
valeur de la variable.
http://minilien.com/?sQNnEIKr4V
[...]En général : dès que l'expression contient une variable
globale, ou une variable dont on a pris l'adresse (y compris
en forme de référence), et que la boucle contient le moindre
appel à une fonction dont le compilateur ne voit pas
l'implémentation, le compilateur est obligé à supposer que
cette fonction change la valeur de la variable.
http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
[...]
En général : dès que l'expression contient une variable
globale, ou une variable dont on a pris l'adresse (y compris
en forme de référence), et que la boucle contient le moindre
appel à une fonction dont le compilateur ne voit pas
l'implémentation, le compilateur est obligé à supposer que
cette fonction change la valeur de la variable.
http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
[...]En général : dès que l'expression contient une variable
globale, ou une variable dont on a pris l'adresse (y compris
en forme de référence), et que la boucle contient le moindre
appel à une fonction dont le compilateur ne voit pas
l'implémentation, le compilateur est obligé à supposer que
cette fonction change la valeur de la variable.
http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
En somme, Microsoft te donne la possibilité de dire
explicitement ce qu'il ne pourrait pas déduire (parce que
l'information se trouve dans une autre unité de compilation).
Je m'étais gourré dans mon minilien, il y avait également /Og, mais il
La norme C donne aussi une possibilité de declarer certains
paramètres « restrict » -- grosso modo, c'est une promesse que
l'objet désigné par un pointeur n'est pas accédé autrement que
par ce pointeur.
Vous expliquez mieux que la norme C ...
Je ne suis pas expert dans la matière, mais les deux solutions
me semblent surtout ajouter aux risques d'un comportement
indéfini. J'aurais tendance à les éviter sauf en cas de
nécessité.
Cette option, elle signifie en gros: "Compilo, nom ami, je te jure que
http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
En somme, Microsoft te donne la possibilité de dire
explicitement ce qu'il ne pourrait pas déduire (parce que
l'information se trouve dans une autre unité de compilation).
Je m'étais gourré dans mon minilien, il y avait également /Og, mais il
La norme C donne aussi une possibilité de declarer certains
paramètres « restrict » -- grosso modo, c'est une promesse que
l'objet désigné par un pointeur n'est pas accédé autrement que
par ce pointeur.
Vous expliquez mieux que la norme C ...
Je ne suis pas expert dans la matière, mais les deux solutions
me semblent surtout ajouter aux risques d'un comportement
indéfini. J'aurais tendance à les éviter sauf en cas de
nécessité.
Cette option, elle signifie en gros: "Compilo, nom ami, je te jure que
http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
En somme, Microsoft te donne la possibilité de dire
explicitement ce qu'il ne pourrait pas déduire (parce que
l'information se trouve dans une autre unité de compilation).
Je m'étais gourré dans mon minilien, il y avait également /Og, mais il
La norme C donne aussi une possibilité de declarer certains
paramètres « restrict » -- grosso modo, c'est une promesse que
l'objet désigné par un pointeur n'est pas accédé autrement que
par ce pointeur.
Vous expliquez mieux que la norme C ...
Je ne suis pas expert dans la matière, mais les deux solutions
me semblent surtout ajouter aux risques d'un comportement
indéfini. J'aurais tendance à les éviter sauf en cas de
nécessité.
Cette option, elle signifie en gros: "Compilo, nom ami, je te jure que
[...]http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
Je ne suis pas expert dans la matière, mais les deux
solutions me semblent surtout ajouter aux risques d'un
comportement indéfini. J'aurais tendance à les éviter sauf
en cas de nécessité.
Cette option, elle signifie en gros: "Compilo, nom ami, je te
jure que ne fais pas l'abruti en modifiant en loucedé mes
variable par des pointeurs occultes (et des __asm ?), optimise
à ta guise". L'exemple donné n'est pas convaincant (il suffit
de faire l'addition avant la boucle). Mais dans d'autres cas,
pourquoi pas ?. En #pragma, bien sûr.
[...]
http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
Je ne suis pas expert dans la matière, mais les deux
solutions me semblent surtout ajouter aux risques d'un
comportement indéfini. J'aurais tendance à les éviter sauf
en cas de nécessité.
Cette option, elle signifie en gros: "Compilo, nom ami, je te
jure que ne fais pas l'abruti en modifiant en loucedé mes
variable par des pointeurs occultes (et des __asm ?), optimise
à ta guise". L'exemple donné n'est pas convaincant (il suffit
de faire l'addition avant la boucle). Mais dans d'autres cas,
pourquoi pas ?. En #pragma, bien sûr.
[...]http://minilien.com/?sQNnEIKr4V
http://minilien.com/?6C5JzGmym5
Je ne suis pas expert dans la matière, mais les deux
solutions me semblent surtout ajouter aux risques d'un
comportement indéfini. J'aurais tendance à les éviter sauf
en cas de nécessité.
Cette option, elle signifie en gros: "Compilo, nom ami, je te
jure que ne fais pas l'abruti en modifiant en loucedé mes
variable par des pointeurs occultes (et des __asm ?), optimise
à ta guise". L'exemple donné n'est pas convaincant (il suffit
de faire l'addition avant la boucle). Mais dans d'autres cas,
pourquoi pas ?. En #pragma, bien sûr.
