Discussion :

[nicolas.sitbon]

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...

c'est bien ce que je dis, dans ce cas, il s'agit bien d'un problème de conception: il n'est pas concevable d'allouer un tableau de 10Mo sur la pile.

[Vincent Rogier]

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

Pas du tout !!!

Imagine que ton appli est un démon qui tourne en background 24h/24h.

Un stackoverflow n'est pas satisfaisant du tout ! car il y a rupture complète du service. Qui va t'avertir du souci ?

C'est sur que tout bon débutant qui se respecte se plante sur la gestion des malloc/free...

Mais un débutant ne code pas une application professionnelle qui doit assurer un service continu.

L'allocation dynamique permet de ne pas avoir de perte de service et de pouvoir réagir face à une situation anormale.

Entre faire un tab[n] ou n est connu à l'exécution et un tab = malloc(n*sizeof(element)), c'est blanc bonnet et bonnet blanc.
Sauf pour la libération ou, avec une allocation dynamique, tu maitrises aussi la désallocation.

Donc, je garde mon malloc/free !

[nicolas.sitbon]

Mais un débutant ne code pas une application professionnelle qui doit assurer un service continu.

On en revient à ce que je disais, c'est un problème de conception, tout le monde en environnement professionnel ne code pas des services continus, tout dépend de ce que l'on veut faire.

[Vincent Rogier]

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.

C'est un fait, certes, qui concerne des débutants... et pas des codeurs professionnels qui doivent fournir des applis stables... (en théorie !).

[Vincent Rogier]

On en revient à ce que je disais, c'est un problème de conception, tout le monde en environnement professionnel ne code pas des services continus, tout dépend de ce que l'on veut faire.

On est d'accord.

Mais le stack overflow pour moi n'est pas acceptable même pour une appli graphique ou tout autre application...

[nicolas.sitbon]

On est d'accord.

Mais le stack overflow pour moi n'est pas acceptable même pour une appli graphique ou tout autre application...

Oui je me suis mal exprimé, je ne voulais pas dire "acceptable" dans le sens de résultat, mais justement pour vérifier un problème de conception. Pour moi, si un stack overflow apparaît, c'est qu'on est allé bien trop loin dans ce qu'il ne fallait pas faire.

[Thierry Chappuis]

Oui je me suis mal exprimé, je ne voulais pas dire "acceptable" dans le sens de résultat, mais justement pour vérifier un problème de conception. Pour moi, si un stack overflow apparaît, c'est qu'on est allé bien trop loin dans ce qu'il ne fallait pas faire.

Mais parfois, ce type de problème n'apparaît que dans des conditions exceptionnelles. Il est risqué de se baser sur un stack overflow hypothétique afin de découvrir un éventuel problème de conception.

Thierry

[Emmanuel Delahaye]

Oui je me suis mal exprimé, je ne voulais pas dire "acceptable" dans le sens de résultat, mais justement pour vérifier un problème de conception. Pour moi, si un stack overflow apparaît, c'est qu'on est allé bien trop loin dans ce qu'il ne fallait pas faire.

La surveillance de la pile n'est pas requise par la norme[1] et dans la pratique, si elle existe, c'est souvent une option (qui ralentit un peu l'exécution). Donc on ne peut pas du tout compter dessus.

------------------------
[1] j'ai eu le cas en embarqué où un simple appel à sprintf() faisait exploser la pile parce qu'à ce moment là de l'application (démarrage, test mémoire...), celle-ci faisait 200 octets de mémoire physique en dur (mémoire interne du 68302), ce qui a entrainé l'écriture de mon module CLIB/ED/ITOA

[gl]

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,

Donc dans ce cas, on se passe de VLAs. On en arrive bien à la même conclusion, l'erreur est bien ici d'utiliser ces VLAs.

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 suis bien d'accord que l'utilisation des VLAs est, de prime abord, plus simple.
Et c'est d'ailleurs un problème, une solution trop simple est généralement utilisé sans réflexion. Fatalement, un jour ou l'autre quelqu'un va coder le fameux "10Mo dans la pile" (ou plus probablement, demander une taille à un utilisateur qui va taper n'importe quoi, lire cette taille dans un fichier qui vient d'être corrompue, etc.).

Je n'ai jamais été confronté au problème de stack overflow malgré l'utilisation intensive que je fais des VLAs,

Utilisé correctement et avec parcimonie dans un environnement contrôlé sur des tailles de tableaux limitée, il y a de grande chance que ça ne pose pas de problème.
Le souci est bien que l'on ne se situe pas toujours dans le cas optimal.

Et dans le cas de figure idéal, il est généralement tout aussi simple d'utiliser un simple tableau de taille suffisante (quitte à gaspiller un peu)

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 prétends pas que l'allocation/désallocation est la panacée, mais au moins les cas de ressources indisponibles sont gérables, ce qui n'est pas le cas avec les VLAs.

Je ne dis pas que les VLAs sont LA solution miracle, mais simplement une bonne nouveauté du C99.

Autant le principe de base des VLAs me plait beaucoup autant la version "C" ne m'emballe pas vraiment.

[diogene]

Si le VLA est un tableau local, il n'apporte pratiquement rien par rapport à un tableau géré par malloc/free. Le malloc est dans la fonction et le free également : c'est facile à gérer et si on oublie le free, on détecte très vite l'erreur; en plus, on n'encombre pas la pile.

La seule chose que je vois que l'on ne peut pas faire sans VLA, concerne le cas du passage à une fonction, en paramètre, d'un tableau à plusieurs dimensions. Alors, la fonction peut traiter des tableaux à plusieurs dimensions dont la valeur des dimensions n'est pas fixée en utilisant la syntaxe habituelle et sans recourir à des tableaux (1D) de pointeurs.

Tout ça pour dire que l'apport des VLA est pour moi assez minime.

[camboui]

VS2010 supportera-t-il C99 ?

[Emmanuel Delahaye]

VS2010 supportera-t-il C99 ?

A ma connaissance, MS fait l'impasse sur C99, non je dirais non.

[Melem]

D'après Visual C++ 2010 ANSI Conformance

Microsoft® C conforms to the standard for the C language as set forth in the 9899:1990 edition of the ANSI C standard.

La norme ISO/IEC 9899:1990, c'est la norme "C90". Il est indiqué le Visual C++ 2010 sera conforme à la norme C90, c'est tout. La dernière mise à jour (Technical Corrigendum 2) de cette norme date de 1996, c'est-à-dire 3 ans avant la publication du C99.

[Médinoc]

Font ch**r à s'obstiner, surtout pour des trucs qui ne dépendent pas du compilo mais du SDK et ne sont pas testables par le préprocesseur (comme stdint.h)...

[Pouet_forever]

Pour les types contenus dans stdint.h tu as l'équivalent sous windows si je ne dis pas de bêtises c'est : INT16, INT32 et sûrement d'autres
Il suffit d'inclure windows.h

[Médinoc]

Mais si je veux stdint.h (ou plus, stdbool.h), c'est pour la portabilité: INT16 et INT32 n'existent pas sous *n*x...

Et là encore, pas de solution dans le préprocesseur: pas de #ifexist <stdint.h> ou de #iftypedef int32_t...

[Thierry Chappuis]

Définitivement, je n'ai pas l'impression que le compilateur C est aujourd'hui encore un outils stratégique pour Microsoft.

[Vincent Rogier]

Définitivement, je n'ai pas l'impression que le compilateur C est aujourd'hui encore un outils stratégique pour Microsoft.

C'est vrai.

Par contre, cela ne me dérange pas que MS ne supporte que tres partiellement le C99 (notons tout de même le long long et wchar_t) car, ce n'est que mon avis à moi, la plupart des modification de la révision 99 ne servent pas a grand chose et sont peu utiles (toujours à mes yeux), si ce n'est les macros variadics.... Certains éléments, comme la déclaration de variable n'importe ou, toujours à mes yeux, sont une belle connerie. La plupart des modifs du C99 sont plus la pour gommer les différences syntaxique entre C et C++ qu'autre chose...

Ma foi...

[Médinoc]

Les modifs du compilo C99 m'importent peu, mais c'est la bibliothèque standard que je trouve plus importante:

• <stdint.h>, <stdbool.h>: Enfin des types fixes supposés mettre tout le monde d'accord, et marcher sur tout SDK compatible C99! C'est-à-dire, euh...
• Le vrai snprintf() qui retourne seulement la taille quand on lui passe un buffer nul.

[souviron34]

Par contre, cela ne me dérange pas que MS ne supporte que tres partiellement le C99 (notons tout de même le long long et wchar_t) car, ce n'est que mon avis à moi, la plupart des modification de la révision 99 ne servent pas a grand chose et sont peu utiles (toujours à mes yeux), si ce n'est les macros variadics.... Certains éléments, comme la déclaration de variable n'importe ou, toujours à mes yeux, sont une belle connerie. La plupart des modifs du C99 sont plus la pour gommer les différences syntaxique entre C et C++ qu'autre chose...

Ma foi...

+1000

Les modifs du compilo C99 m'importent peu, mais c'est la bibliothèque standard que je trouve plus importante:

• <stdint.h>, <stdbool.h>: Enfin des types fixes supposés mettre tout le monde d'accord, et marcher sur tout SDK compatible C99! C'est-à-dire, euh...
• Le vrai snprintf() qui retourne seulement la taille quand on lui passe un buffer nul.

bof...

• Faire un test n'est quand même pas si terrible que ça, et de plus permet d'afficher un message que ça s'est mal passé quelque part..
  
  
• stdint, je nen vois strictement aucun intérêt
  
  
• Quant à stdbool, soit, c'est intéressant.. Mais encore une fois, comme je l'ai déjà dit plusieurs fois, n'importe qui pendant 25 ans a toujours fait soit bool = int soit bool = char....
  
  Et comme le vrai de vrai type bool n'existe pas, bof, l'intérêt me semble totalement limité...
  
  (d'ailleurs, la manipulation de booléens en C est quand même très très ancienne.... X11 en 1978 puis 1984 avait déjà défini les True, False, et les fonctions retournant des booléens.. Et que je sache le code existant aujourdhui de XFree86 ou de X11 est toujours celui-là..)

Bon, ce n'est qu'une opinion, mais même l'ajout de ceci ne me convainc pas suffisamment pour autoriser des incompatibilités prônées par le C99 (comme le changement des caractères de commentaires, les déclarations n'importe où, etc etc), qui, on le voit tous les jours sur le forum, n'amènent en général que des fouillis notoires (et que l'on retrouvera malheureusement longtemps dans les codes un peu partout) et surtout une incompatibilité avec les anciens codes qui marchent, et donc l'obligation de les migrer (au risque donc d'y introduire des bugs et une moindre lisibilité).


De même que des "features" d'obsolescence dont on revient (les tempname par raport aux tmpnam etc etc)