j'ai récemment entendu parler de static analysis et static analyzer dû au fait que j'ai récemment installé Clang pour expérimenter le compilateur, en raison des écrits de Scott Meyers, qui encourage à travailler sur divers compilateurs pour comprendre les notions de portabilité.
Cela m'a amene à voir parler de static analysis.
J'aurais besoin de comprendre la différence avec le debugging , et surtout ce que cela, dans vos mots à vous, signifie la static analysis en C++ (par exemple avec cpp check. Gabor Horvath a donné une conférence en anglais dessus).
Car à vrai dire, je ne suis pas certain de bien comprendre ce que signifie static analysis :
voici comment j'ai compris cela : en gros, c'est une source de compilation qui se fait en permanence durant l'écriture même du code, visant à détecter dès l'écriture préliminaire d'éventuels bugs.
Merci à vous
- Edité par pseudo-simple 5 décembre 2018 à 11:59:45
>J'aurais besoin de comprendre la différence avec le debugging
Aucun rapport.
J'ai l'impression que vous faites des films.
le "static" de "static analysis" est à comprendre comme en opposition à "dynamic analysis".
Dans l'analyse dynamique, on analyse durant l'exécution du programme.
En static, c'est beaucoup plus simple, on analyse de code source (voir l'exécutable avec certain outils) sans l'exécuter.
C'est comme des compilateurs méga-relou qui font des analyses de problèmes potentiels bien plus approfondi que ce que fait un compilateur qui ne doit que vérifier la conformité du code à la norme.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
"En informatique, la notion d’analyse statique de programmes couvre une variété de méthodes utilisées pour obtenir des informations sur le comportement d'un programme lors de son exécution sans réellement l'exécuter. C'est cette dernière restriction qui distingue l'analyse statique des analyses dynamiques (comme le débugage ou le profiling) qui s'attachent, elles, au suivi de l’exécution du programme."
Tu dis ça parce que tu ne connais pas très bien ce domaine. Il existe un domaine qui s'appelle "la preuve de programmes" qui tu devrais lire. Je connais un tuto d'introduction sur le sujet si tu veux...
C'est vrai que plus simple pour l'analyse statique, c'est pas l'adjectif que j'ai choisi
Après j'ajouterai que le debuging, ca peut être entendu au sens large "trouver des bugs", dans ce cas l'analyse statique et/ou dynamique permettent de faire du debuging dans tous les cas. Mais effectivement, le "debuger" est un outil d'analyse dynamique.
En analyse dynamique on a grosso modo 2 cas d'usages, le premier, c'est le débogage, on sait qu'il y a un bug sur un cas d'usage plus ou moins bien documenté, le but est d'identifier le bug avec pour objectif évident de le corriger. Le second, c'est l'optimisation, on a un jeu de données qui produit une exécution correcte mais avec un problème manifeste de performance, généralement révélé par les phases de tests de montée en charge. L'objectif ici est d'identifier la source du problème de performance, dans l'espoir qu'il sera possible d'optimiser le code correspondant.
L'analyse statique se situe bien en amont, là aussi il y a deux cas d'usages. Le plus courant, c'est la précision du compilateur dans ses warnings, c'est à dire sa capacité à aider le développeur a produire son code (d'où l'importance de toujours travailler avec un compilateur bien configuré, un compilateur bien configuré est capable de reporter un nombre assez incroyable d'erreurs potentielles). Cela va commencer par repérer par exemple une comparaison signée/non signée, une variable non initialisée... Le second cas est la preuve de programme, là, l'objectif est beaucoup plus ambitieux, il s'agit d'apporter une preuve mathématique que le programme est conforme.
L'analyse statique se place en amont de la phase de test, elle est fondamentalement préventive. L'analyse dynamique se place en aval, elle est surtout curative.
A noter qu'on peut aussi prendre le meilleur des deux mondes.
Par exemple, une possibilité est d'utiliser un analyseur statique pour classifier déjà une partie des alarmes comme possibles ou impossible, puis instrumenter le code automatiquement pour les alarmes non-classifiées, ce qui va permettre de réduire l'overhead de l'analyse dynamique.
Ou encore utiliser de la générations automatique de tests (dynamique donc) pour déterminer si un échec de preuve est dû à une sous-spécification, une vraie erreur dans le code, ou une insuffisance des prouveurs, en tentant de générer des contre-exemples lorsqu'une preuve échoue.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C