bijour,
 
Voilà je voulais savoir qu'elle expérience vous aviez sur une api écrite en c sous unix portée sous windows, genre les pt'its points qui peuvent vous pourir la vie sous l'OS de Kro$oft qui passe très bien sous unix...
 
mici.

Tiens bizarre moi ce sont les appels système Windows qui me pourrissent la vie sous unix. Comme quoi la vie est vraiment mal faite.

arf... c'est sûr que tout ce qui est appel système peut être contrariant. Mais bon... il peut y avoir des problèmes plus substils?

ben si tu precises pas...

 
Comment veux tu que je précise, vu que je demande justement si vous connaissez des cas de figures...

 
ben si t'utilises deux printfs et 3 scanfs, non, ca devrait aller

Nan, c'est pas le cas:p... J'ai cru comprendre apparament qu'il faut par exemple faire attention avec les déclarations de grands tableaux sous windows, il vaut mieux faire du malloc à cause de la pile.

(la verité c'est qu'il ne me viendrait pas a l'idee de declarer des tableau de grandes tailles en local)

Y'a longtemps peut etre. De nos jours, ca doit pas etre different de ce qu'on peut faire sous unix.
Et qu'appelles tu "Grande taille"?
A+,

 
Genre beaucoup:D.
 
ex : char tc[30000][50]

gilou est-ce que tu sais ce à quoi correspond le "heap size" dans l'option d'un compilo?

Pris dans le MSDN
 
A+,

Ouais j'étais tombé dessus, mais je ne suis pas tout à fait d'en avoir compris le mécanisme... tel que je l'ai compris, il s'agit d'une portion de ram réservée à la l'allocation dynamique des variables. Et si c'est 1 Mb par défaut, c'est pas de la folie:D. Le paramètre commit étant la taille d'un bloc?
 
Donne moi ton pt de vue stp gilou...

Bon je ne vais parler que de Windows, et de programmes en C. Quand tu charges ton programme en memoire, l'espace qui lui est alloué sous windows est decoupé en grosso modo 4 zones:
Code, Data, Heap et Stack.
 
*********
* STACK *
*********
 |  |  |
 V  V  V
 
 ^  ^  ^
 |  |  |
*********
*  HEAP *
*********
*  DATA *
*********
*  CODE *
*********
La stack occupe l'espace en croissant vers le bas et la heap en croissant vers le haut (l'espace maximum allouable par un programme est une valeur qui est modifiable, et qui est lue par l'OS au lancement du programme. Le plus souvent, la valeur par defaut suffit).
 
Le section code contient le code du programme, la section data, la memoire statique, la heap la memoire dynamique, et la stack tout le reste, et en particulier les variables locales.
 
Donc si tu a une variable locale de type char tc[30000][50], elle sera allouee dans la stack. Si cette variable etait globale ou si elle etait static, ce serait dans la section data.
Et si c'etait  char **tc = malloc(30000*50) ce serait dans la heap.
 
Bon bien entendu, j'ai hyper simplifié:
L'ordre des sections stack heap data code est l'ordre par defaut et peut etre modifié (option /DO) les sections code et stacks peuvent etre multiples.
De plus, sous windows, en plus de la heap par defaut de son programme, il y a moyen de creer des heaps specifiques au moyen de HeapCreate()
 
 
Dans le modele unix, on a des choses +/- similaires:
une section .text (pour le code), une section .data pour la memoire statique initialisée, une section .bss pour la memoire statique non-initialisée (BSS vient de Block Started by Symbol), une section .heap et une section .stack
Si de plus, c'est du C++ et non du C, on aura eventuellement: une section .init (le startup code), une section .fini (l'exit code), une section .ctor (pour les constructeurs) et une section .dtor (pour les destructeurs)
 
A+,

Ok hormis la pile j'ignorais le reste, t'aurais pas un lien sous le coude stp?
 

Ben cherche sous google avec stack heap data bss et tu en trouveras
A+,