ne m'en parle pas
sinon, bah :
- pour pas polluer les sources avec des trucs non portables quand c'est pas indispensable
- parce qu'on a besoin de changer à la volée les réglages, genre désactiver l'optimisation quand on veut faire du débuggage : pas question de toucher aux fichiers eux-mêmes dans ces cas-là
- parce que les besoins d'optimisation sont au moins autant une propriété du projet entier que du fichier source lui-même : une fonction qui était critique dans une lib fait peut-être maintenant partie d'un module peu critique, donc c'est plus la peine de dérouler les boucles et tout
- parce que ça peut compliquer les choses pour le compilo : certaines optimisations ne sont valables qu'à travers tout un fichier, genre une option qui active le réordonnancement des fonctions au sein d'un même fichier vs. les options par défaut qui ne le feraient pas
je suis d'accord que ce serait bien de pouvoir dire au compilo de façon portable et locale "attention, telle fonction est critique pour la vitesse", et qu'après il puisse en faire ce qu'il veut : si on veut débugger il l'ignore, sinon il passe en -O3... (ce serait plus un léger hint que des vrais flags d'optimisation locaux, donc)
mais de toute façon gcc est capable de tenir compte des infos de profiling, donc même si c'est plus chiant à mettre en place c'est bcp plus précis : évaluation plus fine de la "criticité", pas de risque d'oublier de dire qu'une fonction est critique, et puis c'est toujours à jour (alors que si on réutilise du code dans un autre contexte, les fonctions critiques ne sont a priori plus les mêmes)
