Discussion :

[Vincent Rogier]

GCC n'est pas une fin en soit! ça n'est pas le seul compilateur, et ça n'est pas le meilleur compilateur.

Ok, c'est vrai...

Mais, mettons que tu développes une librairie ou un programme lambda portable que tu veuilles faire fonctionner sur quasiment toute les plateformes linux/unixes.

Sous linux, tu as forcément un gcc.
Sous les différents unixes, tu as forcément un cc (dont tu ne connais pas à l'avance le support pour C99) et éventuellement gcc.

Vas tu prendre le risque que ta librairie ou ton programme ne puisse pas compiler car tu auras utilisé dans 1% de ton code des spécificités C99 ?

Personnellement, je ne préfère pas prendre ce risque.
Je préfère que mon code soit réellement portable sur tous les unixes quitte à me rendre la tâche moins facile dans le code.

[snake264]

Ok, c'est vrai...

Mais, mettons que tu développes une librairie ou un programme lambda portable que tu veuilles faire fonctionner sur quasiment toute les plateformes linux/unixes.

Sous linux, tu as forcément un gcc.
Sous les différents unixes, tu as forcément un cc (dont tu ne connais pas à l'avance le support pour C99) et éventuellement gcc.

Vas tu prendre le risque que ta librairie ou ton programme ne puisse pas compiler car tu auras utilisé dans 1% de ton code des spécificités C99 ?

Personnellement, je ne préfère pas prendre ce risque.
Je préfère que mon code soit réellement portable sur tous les unixes quitte à me rendre la tâche moins facile dans le code.

Entièrement d'accord.

Ce que tu dis n'a pas de sens, quand tu fais un malloc(), tu construis bien un tableau (dans le tas) et généralement à partir d'une variable.

Pourquoi pas de sens VLA veut bien dire ce qu'il veut dire (Variable-Length Array). Et ce qui n'est pas bien avec cela c'est si jamais il n'y a pas assé de place pour créer ton tableau tes fichu car on est pas prévenu d'où l'intéret du malloc.

[Thierry Chappuis]

GCC n'est pas une fin en soit! ça n'est pas le seul compilateur, et ça n'est pas le meilleur compilateur.

Non, mais il est disponible sur toutes les plateformes que j'utilise et qui sont utilisées là où je travaille. La plupart des personnes avec qui je travaille et pour qui je travaille disposent de ce compilateur. C'est un avantage de taille. Comeau est un excellent compilateur, mais je n'ai pas l'envie d'acheter et de faire acheter partout autour de moi des licences pour Dinkumware alors que gcc + C90 fait le job et répond à nos exigences en terme de portabilité.

gcc n'est pas une fin en soit. Ce n'est pas un outils extraordinaire non plus. C'est juste un compilateur C parmi les plus répandus à l'heure actuelle.

Thierry

[nicolas.sitbon]

Vas tu prendre le risque que ta librairie ou ton programme ne puisse pas compiler car tu auras utilisé dans 1% de ton code des spécificités C99 ?

Il est vrai que je n'ai pas problème dans mon travail, mais je pense que personnellement, si j'étais dans ce cas, j'essayerais plutôt de faire avancer les choses, par exemple, en contactant l'équipe charger du développement de GCC pour savoir pourquoi l'avancement est au point mort. 10 ans pour pondre un compilateur conforme, je trouve ça trop long sans compter le nombre d'extensions propriétaires qui n'ont rien à voir avec le standard. C'est pour cela que j'utilise Sun Studio.

[nicolas.sitbon]

Et ce qui n'est pas bien avec cela c'est si jamais il n'y a pas assé de place pour créer ton tableau tes fichu car on est pas prévenu d'où l'intéret du malloc.

Un stack Overflow n'est pas suffisant pour toi en terme d'avertissement!

[Melem]

Vas tu prendre le risque que ta librairie ou ton programme ne puisse pas compiler car tu auras utilisé dans 1% de ton code des spécificités C99 ?

. Elle me plaît bien cette question. Et ce 1% c'est généralement snprintf ... Pour ma part, si la plateforme cible est Windows uniquement, j'utilise sprintf_s (version "sécurisée" de sprintf car même _snprintf est dépréciée en faveur de _snprintf_s). Sinon, je fais aussi comme Thierry.

[souviron34]

Et ce 1% c'est généralement snprintf ...

plus les commentaires C++-style

[Thierry Chappuis]

Il est vrai que je n'ai pas problème dans mon travail, mais je pense que personnellement, si j'étais dans ce cas, j'essayerais plutôt de faire avancer les choses, par exemple, en contactant l'équipe charger du développement de GCC pour savoir pourquoi l'avancement est au point mort. 10 ans pour pondre un compilateur conforme, je trouve ça trop long sans compter le nombre d'extensions propriétaires qui n'ont rien à voir avec le standard. C'est pour cela que j'utilise Sun Studio.

Ce n'est pas si simple que tu sembles le penser. Pondre un compilateur conforme pour une plateforme bien déterminée, c'est beaucoup de travail, mais c'est possible dans un laps de temps raisonnable et avec une équipe compétente. Avec gcc, le problème est que ce compilateur ne vise pas une seule architecture. C'est bien des problèmes de portabilité qui ralentissent le développement de ce complio. Ce n'est pas trivial d'écrire un compilateur utilisable sur pratiquement tout ce qui existe.

Thierry

[Vincent Rogier]

Il est vrai que je n'ai pas problème dans mon travail, mais je pense que personnellement, si j'étais dans ce cas, j'essayerais plutôt de faire avancer les choses, par exemple, en contactant l'équipe charger du développement de GCC pour savoir pourquoi l'avancement est au point mort. 10 ans pour pondre un compilateur conforme, je trouve ça trop long sans compter le nombre d'extensions propriétaires qui n'ont rien à voir avec le standard. C'est pour cela que j'utilise Sun Studio.

C'est pas le fait de contacter l'équipe core de GCC qui résoudra le problème de portabilité... Car je pense qu'ils sont conscient de l'état de GCC par rapport au C99 et que d'autres personnes ont déjà du les contacter.

Personnellement, quand je veux faire du portable, je n'utilise aucune extension quelque qu'elle soit (GCC, VS, ...) au C90.

Le problème ne réside pas dans le fait d'utiliser tel ou tel compilo (j'utilise VS sous Windows et GCC sous linux), mais quel est le compilo disponible sur la plateforme ou sera déployée ton appli ou ta librairie !
Et ca tu ne peux pas toujours le maitriser.
Peux tu imposer à tes clients ou aux utilisateurs de tes produits d'utiliser Sun Studio s'ils ne l'utilisent pas ? Je ne pense pas...

Si je prends le cas d'une de mes librairies OCILIB, en restant fidéle au C90 (et petite dérogation optionnelle C99 pour l'unicode), elle est compilable par tous les compilateurs du marché... Je ne peux imposer à mes utilisateurs d'utiliser Sun Studio sur un HP/UX 64bits par exemple...

[Vincent Rogier]

. Elle me plaît bien cette question. Et ce 1% c'est généralement snprintf ... Pour ma part, si la plateforme cible est Windows uniquement, j'utilise sprintf_s (version "sécurisée" de sprintf car même _snprintf est dépréciée en faveur de _snprintf_s). Sinon, je fais aussi comme Thierry.

Même si les versions sécurisées de la CRT de MS partent d'une bonne intention, je ne les utiliserai jamais car non standard et non portables.
Je préfère sécuriser mon code et qu'il soit portable que de me lier à MS et lui déléguer des contrôles applicatifs

[Thierry Chappuis]

Mis à part "l'officialisation" de la gestion des caractères larges

<HS>Si je ne me trompe pas, la gestion des caractères larges a été introduite dans le 1er amendement à C90 (C95), non?</HS>

Thierry

[snake264]

Un stack Overflow n'est pas suffisant pour toi en terme d'avertissement!

Personnellement non, je n'apprécie vraiment pas certains aspect de cette norme. Hormis certaines fonctionnalité qui est propre a chacun d'aimer ou non et d'utiliser, le niveau de portabilité est affreux, j'en veux pour preuve que en cours lorsque l'on rend des projets aux profs ils n'ont pas tous le même OS et énormément d'entre nous jure aussi par le C99 et ce ramasse des mauvaises notes car le prof n'a pas réussi à le compiler soit sur gcc soit sur VS ou un autre et il ne cherche pas à corriger les fautes sa compile ta la moyenne sa compile pas c'est en dessous peut importe si le code est parfait ou non. Et je pense que c'est pareil dans le monde du travail lorsque l'on doit livrer un code et on ne sait pas sur quel système il va tourner.

Ensuite pour ce qui est de l'implémentation dans gcc ou dans les autres je pense que si cela n'a pas été fais entièrement depuis tout ce temps c'est qu'il y a une bonne raison...

[Vincent Rogier]

<HS>Si je ne me trompe pas, la gestion des caractères larges a été introduite dans le 1er amendement à C90 (C95), non?</HS>

Thierry

En fait, C90 a introduit wchar_t, C95 a ajouté des fonctions et C99 a encore ajouté des fonctions

[Médinoc]

Personnellement, je me moque des VLA. Mais j'apprécie snprintf(), et surtout le fait qu'on ait désormais des typedefs "standard" pour des choses que chaque environnement refaisait à sa manière: Notamment le type booléen (accompagné de son en-tête stdbool.h) et les types à taille donnée (stdint.h, inttypes.h).

Les macros variadiques peuvent être un plus, tout comme les initialiseurs de champs (plus pour les unions que pour les structures, en ce qui me concerne), mais bossant sous Visual, je m'en passe pour l'instant (pour snprintf(), je suis obligé de me faire un wrapper de _snprintf_s() et _scprintf() pour l'instant).

Par contre, ce que je reproche aux organismes de normalisation, c'est de ne pas avoir inclus strtok_r() au standard. Mais je suis content qu'ils aient enfin déprécié gets() dans le n1256.

[gl]

Un stack Overflow n'est pas suffisant pour toi en terme d'avertissement!

Non ce n'est pas suffisant.

Un arrêt brutal du programme en cas de manque ponctuelle n'est pas toujours la bonne solution.
Avec malloc() si la mémoire manque, le programme est averti de l'erreur et peut prendre des mesures (nouvel essai ultérieur, libération d'autres ressources non-critiques, arrêt propre du programme, log de l'erreur, fonctionnement en mode "dégradé" sans la fonctionnalité ayant provoqué l'erreur, etc.)
Avec unstack overflow, le programme s'arrête violemment, il est possible que ce soit suffisant dans certains, mais ce n'est pas toujours vrai (notamment sur des systèmes de sécurité ou ayant besoin d'une très grande disponibilité).

[nicolas.sitbon]

Non ce n'est pas suffisant.

Un arrêt brutal du programme en cas de manque ponctuelle n'est pas toujours la bonne solution.
Avec malloc() si la mémoire manque, le programme est averti de l'erreur et peut prendre des mesures (nouvel essai ultérieur, libération d'autres ressources non-critiques, arrêt propre du programme, log de l'erreur, fonctionnement en mode "dégradé" sans la fonctionnalité ayant provoqué l'erreur, etc.)
Avec unstack overflow, le programme s'arrête violemment, il est possible que ce soit suffisant dans certains, mais ce n'est pas toujours vrai (notamment sur des systèmes de sécurité ou ayant besoin d'une très grande disponibilité).

Il faut faire la part des choses, généralement un stack overflow de ce type relève plus d'un problème de conception qu'autres choses.

[gl]

Il faut faire la part des choses, généralement un stack overflow de ce type relève plus d'un problème de conception qu'autres choses.

Ah !
Soit je décide donc d'utiliser les VLA et un beau jour, la création du tableau n'a pas pu se faire (taille trop importante par rapport à la mémoire libre) et bien entendu la programme n'a pas pu réagir (puisqu'il n'y a pas de retour d'information) et le programme plante. Où se situe le problème de conception (si ce n'est dans l'utilisation des VLA) ?

Je suis d'accord que sur des machines où la mémoire disponible est surestimée par rapport aux besoins ou dans le cas de tableau de faible taille, ce problème est très peu probable mais malheureusement on ne se trouve pas toujours dans le cas idéal.

A titre d'information, un problème similaire se pose avec l'utilisation de "l'allocateur optimiste" de Linux.

[nicolas.sitbon]

Où se situe le problème de conception (si ce n'est dans l'utilisation des VLA) ?

bas bêtement, ça peut être un problème de récursivité, où plus simplement de bon sens, exemple, j'alloue un tableau de 10Mo sur la pile, maintenant dans la plupart des cas, l'utilisation des VLAs peut simplifier l'écriture du code ainsi que ça maintenance (pas de problème lié à free() ). Je n'ai jamais été confronté au problème de stack overflow malgré l'utilisation intensive que je fais des VLAs, en revanche, on passe notre temps sur ce forum à corriger des problèmes d'allocations/désallocations et ça c'est un fait. Je ne dis pas que les VLAs sont LA solution miracle, mais simplement une bonne nouveauté du C99.

[Médinoc]

Déjà, allouer un tableau de 10 Mo sur la pile, sous Windows, par défaut c'est mort (la pile, par défaut, fait 1 Mo).
Donc, si tu mets, par exemple, le contenu d'un fichier dans un VLA, attends-toi à de mauvaises surprises...

[Thierry Chappuis]

Déjà, allouer un tableau de 10 Mo sur la pile, sous Windows, par défaut c'est mort (la pile, par défaut, fait 1 Mo).
Donc, si tu mets, par exemple, le contenu d'un fichier dans un VLA, attends-toi à de mauvaises surprises...

+1