Pollux
:Oui enfin si la différence est suffisamment importante pour avoir une différence de performance significative à un endroit critique du programme et que les gens de la lib n'ont pas pensé à faire une version sans ce paramètre supplémentaire, c'est peut-être que cette lib n'est pas adaptée et pas pensée pour l'optimisation ? (sans compter que si ça a déjà un impact important sur la performance avec des optimisations faites par le compilo, ça risque d'être nettement mieux avec une fonction de la lib plus adaptée)

Ben pas forcément... J'ai parlé de paramètres appellés avec toujours la même valeur, pas forcément apellés à leur valeur par défaut... Dans une (très très) moindre mesure, apeller toujours memcpy avec une taille de 32 octets, c'est carrément optimisable (pas forcément inlinable), mais osef de toute les compilateurs que ça concerne ne peuvent pas le faire (compilation séparée)... Et même dans le cas des paramètres par défaut, à moins de trucs très poussés, on se contente souvent d'apeller la fonction qui implémente tout avec ses paramètres par défauts (mm principe que les paramètres optionnels dans certains langaes) plutôt que de s'amuse rarement a recopier/recoder la même chose dans 50 fonctions juste pour l'optimisation... La redondance ça rend le code carrément moins, voire pas du tout maintenable quand même, et ça c'est pas négligeable hein ^^

Pollux :
Un peu comme les templates en C++, en quelque sorte ? (sauf que les templates C++ c'est un peu naze parce que c'est pas du tout général : il faudrait par exemple pouvoir préciser que n'importe lequel des paramètres doit être inliné dans le code de la fonction, sans restriction de type et sans redéfinition de la fonction)

Je connais pas assez les templates en C++, mais je suppose que c'est ça ^^ (Mais bon le C++ tout comme le C, même avec optimisations globales, reste limité par la compilation séparée (sux) et ça ne changera ceratinement pas de si tôt.)

./13 > Effectivement un compilo évolué peut optimiser ça (reste à voir dans quels cas), et je pense que le compilateur (et non pas le JIT cette fois) C# doit certainement le faire, mais là j'ai juste recopié la même chose qu'en C pour le C# c'est tout ...
Et si je défends les hauts niveau sur le fait qu'ils simplifient la vie aux programmeurs, je les défends pas sur le fait de les rendre cons hein...
Si tu vois une [vraie] optimisation à faire (simple qui plus est), alors fais là... Le compilateur l'aurait peut-être fait ou peut-être pas, mais là au moins tu sais que c'est fait. Parce que bon, avec des "le compilateur devrait" tu finis par faire des codeurs fainéants qui ne cherchent même pas l'optimisation, et le compilateur derrière ne doît jamais être une excuse pour ça.
./14 > Pour la question des itérateurs, ça se défend... ou pas ^^ Perso j'aime pas tellement utiliser ça sur les chaînes puisque ça ne te permet pas de connâitre la position où tu es, donc je n'ai pas mis ça dans l'exemple, mais sinon, ça dépend vraiment de la manière dont le langage gère les chaînes... En .NET c'est assez pourrave, bien que totalement compréhensible, (une chaîne est définie comme un type valeur...) mais heureusement tu peux utiliser un StringBuilder qui corrige très bien le défaut, et en Java je sais pas, mais dans tous les cas il faut vraiment pouvoir avoir accès a un équivalent correct à ce que tu ferais en C (buffer temporaire + strncpy).