Discussion :

[dafpp]

Bonjour,
les 'built-in functions' - je ne sais pas comment on dit en français, sont des fonctions propres au compilo, et non au langage, c'est à dire que des fonctions ne pourront marcher que pour certains compilo ?
-- je préfère dire ce que tout le monde sait, pour être sûr de n'avoir pas compris de travers.

Donc, quels sont-elles ? J'aimerai l'éviter quand je la rencontre, donc où peut-on retrouver une liste des fonctions 'built-in', ou au moins, dans mon cas, je serai interessé par gcc.

(il est bon de préciser avec gcc l'option std, pour préciser la norme utilisé ? - cette option desactive ces fonctions built-in)

j'en profite pour demander quelque chose de nouveau:
Est-il conseillé (comme pour les built-in) d'utilisé les extensions des compilos ? pour gcc: comme typeof, les "nested functions", labels, ... y a t-il un intérêt de les utiliser ? Il y a encore un soucis de compatibilité par la suite, mais y a t-il des choses semblables chez les autres compilos ? Est ce que certains éléments rentrent tout de même dans les normes ?

merci d'avance.

[kwariz]

Salut,

Les extensions (donc entre autre les builtins mais aussi les __attribute__ par exemple) sont typique à un compilateur. Si tu les utilises tu seras captif à un compilateur, mais quand tu les utilises tu le sais tout de suite (elles sont repérées et tu ne peux les utiliser par hasard).
Pour GCC, la doc est très fournie et bien faite. L'option std permet de sélectionner le standard c que tu utilises (C89/C99/C11/...). Les builtins sont toujours dispo. Il y a une option -fno-builtin.
Il y a bien sûr un intérêt à les utiliser, par exemple si tu veux tirer avantages des extensions SIMD de ton ia32, des extensions similaires sont dispo sur les autres compilo mais elles ne sont ni stadardisées ni obligatoires.

[dafpp]

ok je vois.
je suis d'accord, mais le mieux, si on a vraiment pas de bonnes excuses, on utilise pas ?

et si on ajoute l'option std, les built-ins sont desactivés, sauf si la valeur et du genre gcc89/99 - si je ne me trompe pas.

[kwariz]

ok je vois.
je suis d'accord, mais le mieux, si on a vraiment pas de bonnes excuses, on utilise pas ?

et si on ajoute l'option std, les built-ins sont desactivés, sauf si la valeur et du genre gcc89/99 - si je ne me trompe pas.

En fait il ne faut pas avoir des excuses mais des raisons. Si tu désires un maximum de portabilité avec un minimum de boulot : ne les utilise pas ; si tu désires un maximum de performance (en général) et que la portabilité est secondaire : utilise les. Les extensions du type sucre syntaxique sont sympa (parfois) mais n'apportent rien en terme de perf et rendent ton code moins portable, je dirais donc : à proscrire.
Certaines extensions sont très utiles (même dans le domaine pro j'autorise par exemple certains __attribute__).

Quant à l'utilisation de std, je laisse la parole à la doc :

By default, GCC provides some extensions to the C language that on rare occasions conflict with the C standard. See Chapter 6 [Extensions to the C Language Family], page 291. Use of the ‘-std’ options listed above will disable these extensions where they conflict with the C standard version selected.

6 Extensions to the C Language Family

GNU C provides several language features not found in ISO standard C. (The ‘-pedantic’ option directs GCC to print a warning message if any of these features is used.) To test for the availability of these features in conditional compilation, check for a predefined macro __GNUC__, which is always defined under GCC.

builtin et extensions sont deux choses différentes.

[dafpp]

Oui d'accord, ça j'avais bien compris que ce n'était pas la même chose.
Les built-ins sont des fonctions apporté par le compilo, qui permettent des fois des nouvelles solutions, des nouvelles manière de faire, ou une amelioration (entre guillemet), comme pour "alloca" - sauf que c'est différent de malloc, étant donné que la mémoire n'est pas alloué dans le tas, mais dans la pile.
-- corrigez moi si je me trompe - vous saurez le faire

Et les extensions, ce sont des nouvelles manières, format, d'écrire du code C. Donc je pense là aux fonctions dans des fonctions, aux labels, ...

Donc j'avais mal lu, simplement, mais je n'ai pas confondu entre les deux, c'est moi qui ai confondu ma phrase

merci pour ces éclaircis.