Mon commentaire n'était pas une attaque de ton commentaire mais un complément. Ce que tu as dit est juste.
> Sinon, certaines choses comme les attributes "pure" ou autres de gcc permettent au compilateur de mieux optimiser, et là, via autoconf ...
Ce sont des "bidouilles" (je ne critique pas la qualité de ces outils qui sont dans la pratique indispensables pour un programme multi-plateforme) pour optimiser ou gérer les différences d'implémentation des compilateurs. Si le standard C était parfait (mais ce n'est pas impossible) et les optimisation automatique toujours bonnes (et là il faut réver fort), ces pratiques ne seraient pas nécessaire. Je le répète, dans la pratique elles sont indispensables.
> utiliser des extensions devient donc nécessaire pour écrire un noyau
> les optimisations qui normalement ne changent rien peuvent modifier le comportement du programme, d'où la nécessité de pouvoir les contrôller dans un noyau.
En effet le standard C ne propose pas grand chose pour la programmation bas niveau (spécification d'adresse des variables, etc...) et n'est pas adapté pour le developpement du noyau. Il n'y a que le mot clé "volatile" dans la norme qui peut interresser un développeur noyau et le mot clé "register" (inutile vu le niveau des compilateurs mais toujours là pour des raisons historiques) et "inline" (rend aussi le code plus propre en évitant des macros et ajoute le controle de paramètres) pour optimiser du code.
Tout ceci est parfaitement normal. Le language C doit être intépendant du hard et le noyau s'occupe du hard. Les missions du standard C sont différentes du noyau voir incompatibles. Il faut donc passer par des extensions.
Pour les extensions de gcc qui ne sont pas dans la norme. Je les adore alors que j'ai pas fait de développement bas niveau :-). J'ai bossé sur OSF-1, HP-UX, Solaris et j'ai toujours utilisé gcc/gdb/ddd en parallèle avec les outils standards car ils sont bien meilleurs.
Bref tout ce blabla pour dire que l'on est d'accord.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . En réponse à la dépêche Comparatif Intel C++ 7.0 / Gcc 3.2.1. Évalué à 1.
> Sinon, certaines choses comme les attributes "pure" ou autres de gcc permettent au compilateur de mieux optimiser, et là, via autoconf ...
Ce sont des "bidouilles" (je ne critique pas la qualité de ces outils qui sont dans la pratique indispensables pour un programme multi-plateforme) pour optimiser ou gérer les différences d'implémentation des compilateurs. Si le standard C était parfait (mais ce n'est pas impossible) et les optimisation automatique toujours bonnes (et là il faut réver fort), ces pratiques ne seraient pas nécessaire. Je le répète, dans la pratique elles sont indispensables.
> utiliser des extensions devient donc nécessaire pour écrire un noyau
> les optimisations qui normalement ne changent rien peuvent modifier le comportement du programme, d'où la nécessité de pouvoir les contrôller dans un noyau.
En effet le standard C ne propose pas grand chose pour la programmation bas niveau (spécification d'adresse des variables, etc...) et n'est pas adapté pour le developpement du noyau. Il n'y a que le mot clé "volatile" dans la norme qui peut interresser un développeur noyau et le mot clé "register" (inutile vu le niveau des compilateurs mais toujours là pour des raisons historiques) et "inline" (rend aussi le code plus propre en évitant des macros et ajoute le controle de paramètres) pour optimiser du code.
Tout ceci est parfaitement normal. Le language C doit être intépendant du hard et le noyau s'occupe du hard. Les missions du standard C sont différentes du noyau voir incompatibles. Il faut donc passer par des extensions.
Pour les extensions de gcc qui ne sont pas dans la norme. Je les adore alors que j'ai pas fait de développement bas niveau :-). J'ai bossé sur OSF-1, HP-UX, Solaris et j'ai toujours utilisé gcc/gdb/ddd en parallèle avec les outils standards car ils sont bien meilleurs.
Bref tout ce blabla pour dire que l'on est d'accord.