Il y a un coût réel en terme d'espace à utiliser les templates. Je discutais récemment avec un mec qui avait bossé pour une boite de télécoms il y a quelques années. Il devait écrire un bout de firmware, ce qu'il fit en C++. Le code était rempli de templates, et plus exactement, il avait fait de la méta-programmation par template. Le binaire qu'il a produit est du coup devenu énorme. Il a eu la chance que l'espace pour stocker le code était suffisamment grand pour contenir tout le code, et du coup utiliser les templates avait payé (s'il y a la place pour le code, le compilateur peut souvent générer du code qui est effectivement très bon).
Le problème n'est pas d'utiliser les templates de façon « simple » (fonction template, etc.), mais bien lorsqu'on utilise les templates de façon « intelligente » (méta-prog par templates), car on perd potentiellement de vue la quantité réelle de code généré, là où en C ou dans un langage OO plus « pur » (par exemple hein), comme on ne dispose pas de cet outil, on aurait programmé la même chose dans un style différent (en utilisant le polymorphisme dynamiquement par exemple).
Donc Pierre Roc, même s'il a pris la réponse un peu mal (de façon injustifiée je trouve), a raison de se poser la question de la duplication du code. Si les templates n'avaient comme inconvénient que la façon dont il faut penser pour faire de la méta-prog, je pense que plus de langages auraient évolué dans ce sens (en proposant sans doute une version simplifiée ou plus programmer-friendly de faire).
Par contre, si on parle de cache d'instructions de processeurs modernes, sur Intel le L1I est généralement de 32Kio de nos jours, et AMD oscille entre 32Kio et 64Kio. Si le programme a besoin de brancher tellement de fois qu'il y a de réels défauts de cache en permanence dans le L1I, il faut commencer à se poser la question de comment le truc a été programmé...
[^] # Re: Et les nouveaux langages de programmation...
Posté par lasher . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Il y a un coût réel en terme d'espace à utiliser les templates. Je discutais récemment avec un mec qui avait bossé pour une boite de télécoms il y a quelques années. Il devait écrire un bout de firmware, ce qu'il fit en C++. Le code était rempli de templates, et plus exactement, il avait fait de la méta-programmation par template. Le binaire qu'il a produit est du coup devenu énorme. Il a eu la chance que l'espace pour stocker le code était suffisamment grand pour contenir tout le code, et du coup utiliser les templates avait payé (s'il y a la place pour le code, le compilateur peut souvent générer du code qui est effectivement très bon).
Le problème n'est pas d'utiliser les templates de façon « simple » (fonction template, etc.), mais bien lorsqu'on utilise les templates de façon « intelligente » (méta-prog par templates), car on perd potentiellement de vue la quantité réelle de code généré, là où en C ou dans un langage OO plus « pur » (par exemple hein), comme on ne dispose pas de cet outil, on aurait programmé la même chose dans un style différent (en utilisant le polymorphisme dynamiquement par exemple).
Donc Pierre Roc, même s'il a pris la réponse un peu mal (de façon injustifiée je trouve), a raison de se poser la question de la duplication du code. Si les templates n'avaient comme inconvénient que la façon dont il faut penser pour faire de la méta-prog, je pense que plus de langages auraient évolué dans ce sens (en proposant sans doute une version simplifiée ou plus programmer-friendly de faire).
Par contre, si on parle de cache d'instructions de processeurs modernes, sur Intel le L1I est généralement de 32Kio de nos jours, et AMD oscille entre 32Kio et 64Kio. Si le programme a besoin de brancher tellement de fois qu'il y a de réels défauts de cache en permanence dans le L1I, il faut commencer à se poser la question de comment le truc a été programmé...