Souvent considéré comme néfaste, car il change le code exécuté, rendant les erreurs aléatoires différente de l'exécution traditionnelle (ce qui généralement est une invocation à valgrind)
Le plus gros défaut c'est surtout que le travail de test et de debugging est essentiellement détruit après que le bug soit corrigé, alors que d'autres méthodes de débiguages (test unitaires p.ex.) créent plus de valeur car ils ne sont pas éphémères.
Enfin plusieurs minutes a linker ? Je ne sais pas sur quelle brouette tu bosses, mais sur un code déjà compilé 1 fois, avec tous les .o le link sur un petit projet d'1,3 million de ligne est inférieur à la minute.
De mémoire il s'agit d'environ 4,5 millions de lignes de code. Le problème vient de VS 2008 qui utilise un cache pour l'incremental linking dont la taille est limitée par l'OS (à cause d'une sorte de mmap vraismeblablement) et cette taille de cache est allégrement dépassée par le projet. Chaque linking repart donc de zéro et ça dure effectivement une poignée de minutes.
[^] # Re: Pas de "bonne" réponse
Posté par Michaël (site web personnel) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.
Le plus gros défaut c'est surtout que le travail de test et de debugging est essentiellement détruit après que le bug soit corrigé, alors que d'autres méthodes de débiguages (test unitaires p.ex.) créent plus de valeur car ils ne sont pas éphémères.
De mémoire il s'agit d'environ 4,5 millions de lignes de code. Le problème vient de VS 2008 qui utilise un cache pour l'incremental linking dont la taille est limitée par l'OS (à cause d'une sorte de mmap vraismeblablement) et cette taille de cache est allégrement dépassée par le projet. Chaque linking repart donc de zéro et ça dure effectivement une poignée de minutes.