Dans une analyse de flot profonde, on étudie non pas le graphe du code, mais le graphe des exécutions possible du code, comme l'expliquait Antoine et Reno. La combinatoire explose donc très vite.
Avec un code du style
Bloc A
if (cond1)
_ if (cond2)
_ Bloc C
_ else
_ Bloc C'
else
_ Bloc A''
end if
Bloc B
Dans ce genre de cas (fréquent), tu cherches à analyser l'ensemble des intervales de valeur dans lesquels peuvent se trouver tes variables (n'oubli pas que ton code est réduit selon les primitives que j'ai donné plus haut), en effet, il faut faire des suppositions sur les chemins d'exécution pour détecter ceux qui ne seront jamais pris, malgré les apparences.
Avec deux boucles imbriqués, tu dois tester le devenir de toutes les variables du bloc A en fonction des branchements sur cond1,cond2.
En d'autres termes, à cause de ces deux if imbriqués, tu es obligé de représenter 4 évolutions possible des variables du bloc A, afin de détecter les intervals possibles, etc..
Posons par exemple que tu déclares une variable n := n*2+1 dans le bloc A...
Tu as 4 évolutions possible de cette variable n, qui peuvent avoir des conséquences dans le code. Ce qui signifie que tu dois (si n est modifié dans plus d'une des 4 branches de test) représenter toute la suite du graphe orienté en 4 versions (!).
Imagine quand tu as 5, 20, 50 niveau de test imbriqués avec des énormes blocs de code à l'intérieur... Ta combinatoire explose.
Ai-je été clair ? :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Compilation lente <=> Analyse de flot
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 3.
Avec un code du style
Bloc A
if (cond1)
_ if (cond2)
_ Bloc C
_ else
_ Bloc C'
else
_ Bloc A''
end if
Bloc B
Dans ce genre de cas (fréquent), tu cherches à analyser l'ensemble des intervales de valeur dans lesquels peuvent se trouver tes variables (n'oubli pas que ton code est réduit selon les primitives que j'ai donné plus haut), en effet, il faut faire des suppositions sur les chemins d'exécution pour détecter ceux qui ne seront jamais pris, malgré les apparences.
Avec deux boucles imbriqués, tu dois tester le devenir de toutes les variables du bloc A en fonction des branchements sur cond1,cond2.
En d'autres termes, à cause de ces deux if imbriqués, tu es obligé de représenter 4 évolutions possible des variables du bloc A, afin de détecter les intervals possibles, etc..
Posons par exemple que tu déclares une variable n := n*2+1 dans le bloc A...
Tu as 4 évolutions possible de cette variable n, qui peuvent avoir des conséquences dans le code. Ce qui signifie que tu dois (si n est modifié dans plus d'une des 4 branches de test) représenter toute la suite du graphe orienté en 4 versions (!).
Imagine quand tu as 5, 20, 50 niveau de test imbriqués avec des énormes blocs de code à l'intérieur... Ta combinatoire explose.
Ai-je été clair ? :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker