Discussion :

[Charlemagne]

Bien sûr que si.
Lorsqu'il fait de l'inlining il peut adapter la fonction en fonction de ses paramètres.

Uniquement avec des constantes... ce qui rend l'intérêt quasi nul... puisque le programmeur aurait également pu le faire!

Le compilateur est d'ailleurs probablement plus malin que toi pour optimiser.

J'en doute fort.
Plus malin que toi... sûrement...

[progfou]

Sans être méchant, il est évident que le compilateur, voyant une valeur constante, optimise de lui-même.
Il est également évident que ce n'est pas mon cas, car j'utilise des variables...

[nicroman]

Uniquement avec des constantes... ce qui rend l'intérêt quasi nul... puisque le programmeur aurait également pu le faire!

Pas uniquement sur des constantes... Si je construis une class Segment { x0, x1 }, avec une fonction "length" en inline qui va a priori faire un { return abs(x1-x0); }. Comment puis-je optimiser ca ? Pas possible !

Par contre, le compilateur, lui, a connaissance du context appelant, et va donc optimiser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
int l;
{
    Segment test(0,5);
    int l = test.length();
}

en....

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
int l = 5;

Mieux encore, les compilateurs connaissent les valeurs possibles d'une variable... Et optimisent en fonction de cette information.
D'ou l'importance de l'utilisation des assert() dans le code. Non seulement ils permettent de s'assurer d'une précondition, mais donnent d'excellentes indications au compilateur (__assume sous Visual).

[Charlemagne]

T'as rien compris.
Tu ne fais que transposer la constante....intérêt quasi nul...

Dans ton exemple, j'aurais pu également te donner la valeur de la longueur de ton segment.
Demande donc plutôt à l'utilisateur d'entrer les coordonnées du segment...

[progfou]

Je rejoins Charlemagne (ça c'est rigolo à dire/écrire...) !
Evidement qu'il va optimiser, tu lui donnes des valeurs constantes dans le code.
Si tu fais intervenir des variables tenant sur 4 octets (ou plus) il ne va pas s'amuser à calculer tous les possibles (2^32 dans ce cas) et évaluer chaque cas...

Si tu fais ça comme code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
int l,i,j;
{
for (i=0 ; i< 3000000 ; i++)
{
    for(j=0;j<251000;j++)
    {
        Segment test(i,j);
        l = test.length();
        printf("l = %d", l);
    }
}
}

Je doutes qu'il arrive à optimiser...

[Charlemagne]

Merci du soutien.

Petite remarque:
En l'occurrence je sais que mon compilo (Intel Compiler) sait optimiser ta boucle car il remarquera que la variable locale 'l' n'est pas utilisée et ne va pas faire de boucle du tout! Les autres compilos savent probablement l'optimiser également.
C'est différent par exemple si tu affiches les résultats à l'écran...

[progfou]

J'ai édité .

[nicroman]

T'as rien compris.
Dans ton exemple, j'aurais pu également te donner la valeur de la longueur de ton segment.

Oui, parceque tu sais sémantiquement ce que length() "devrait" faire... si par contre, à un moment, un programmeur change le length() en abs(x1-x0)/2 par exemple, ton optimisation manuelle ne tient plus, et pire, casse le code sans que personne ne puisse s'en apercevoir sauf toi.

C'est la base du refactoring. Plus le code est optimisé en évitant les appels de fonction "évidents", moins il est refactorisable (et donc maintenable).

Les 'segment', 'length' sont donnés à titre d'exemple, il est bien évidemment idiot de faire ce que je dis sur un 'length()'

Mais bon... on va arrêter là cette disgression

[Charlemagne]

Tu comprends rien à rien...

Et alors, ton programme affichait invariablement la valeur 5, dorénavant il affichera 2.5...
Le compilateur optimise le calcul sur des données constantes! très bien, c'est sympa de sa part...

Tu veux essayer de nous faire croire que tous les sauts sont finalement inutiles dans un programme ou quoi?

[nicroman]

Tu comprends rien à rien...

Je confirme... j'ai rien compris à ton dernier message, mais bon... c'est pas très grave non plus