PureBasic

Voila ce que dit la doc

End [CodeDeSortie]
Termine et quitte le programme de manière correcte à n'importe quel endroit du code source. Le paramètre optionnel 'CodeDeSortie' peut être utilisé pour renvoyer un code d'erreur different de 0 (valeur par défaut) lorsque le programme se termine (souvent utilisé par les programmes en mode console).

dois-je comprendre que je n'ai pas à me préoccuper de fermer une connexion reseau ( CloseNetworkServer(),etc..) si je mets un end , c'est lui qui s'en charge quand je quitte le prog ?

D'une façon générale , c'est valable pour toutes les librairies 2D,3D,network , fichiers , etc ... , les instructions freexxxx() et closexxx() sont gérés automatiquement avec le End ?

ou alors il y a des exceptions à connaitre ?

AllocateMemory()

Syntaxe

*MemoryID = AllocateMemory(Taille)
Description

Alloue une zone mémoire contigüe de la taille spécifiée. Si la quantité de mémoire demandée est disponible, *MemoryID contiendra l'adresse de début de la zone mémoire, ou 0 si la zone n'a pu être allouée.

Note: Toutes les zones mémoire créées sont automatiquement libérées à la fin du programme

Il me semble que la note est sur d'autres comandes donc je pense que tout est libéré

ben justement comme je ne retrouve pas cette note dans la section network , je me posais la question .

Je viens de penser à un test simple , si je fais un CreateNetworkServer(Port) et que je quitte le programme sans mettre de end , ni fermer la connexion , puis lancer un autre prog qui teste le port , et je serai fixé non ? ou il y a une faille dans ce raisonnement ?

bon je vais déjà faire ce test , pour voir .

En principe,
Purebasic utilise le "RessourceTracking"

C'est à dire que Pure ferme comme un grand tout ce qui a été ouvert, créé, etc... par Purebasic itself !!!!

mais par contre, très important, toutes ressources allouées via tout autre API ( je fais particulierement allusion à l'API Win32 ) doivent être manuellement libérées soi meme !!!!

par exemple CreateThread() sera libéré lors d'un End
mais pas SetTimer_() etc...

en voila une bonne nouvelle ,mes doutes s'estompent

ceci dit dans certains cas très particulier
il est préférable de libérer nos ressources nous meme
quand du fait de la structure du programme on voudrait libérer les ressources dans l' "ordre" qui nous arrange et non l'ordre d'allocation pris en charge par le RessourceTracker

c'est tres rare et j'ai meme pas d'exemple a te donner

peut etre que Fred peut preciser la chose...

enfin bon

moi ca fait 3 ans que j'utilise pure ( a peu pres )
et dans tout mes progs je laisse faire pure.
il se débrouille tres bien

j'ai toujours une procedure Quitter( Erreur )

dans laquelle je libere les ressources non trackées (les api)
et je fais un petit End qui va bien pis c tout

dans certains cas très particulier
il est préférable de libérer nos ressources nous meme

c'est sûrement des cas que je ne rencontrerai jamais

j'ai du mal à voir quelle importance ça peut avoir l'ordre de libération des ressources ?

Enfin je vais donc continuer à ne pas me casser la tête et laisser faire purebasic

voilà, t'as raison ( merci pure )

meme si çà fait criser les programmeurs C++

Un truc qui me laisse perplexe:
Quand un processus se termine, le système ne peut pas libérer lui-même la mémoire vive/virtuelle qu'il lui avait gentiment prêtée?
Le système est censé être au courant de l'état de la mémoire, non?
Et quand on termine un processus "de force", qu'est-ce qui se passe?

un processus, donc en gros un exe fait avec purebasic integre au sein meme de l'exe les routines de RessourceTracking

heureusement sinon le principe ne peut pas fonctionner
et certes certains diront, beuuhhh, ca fait grossir l'exe, mais l'avantage est enorme.

par ailleurs un processus qu'on "kill" nous meme recoit en realité un message, un signal qui informe le prog de se fermer là maintenant tout de suite. n'empeche c encore l'exe lui meme qui gere son arret
et si windows ne peut rien en tirer du prog qui plante alors là oui ya des soucis mémoire

Mais je ne comprend pas d'où viens l'espace mémoire (on dit le heap je crois) alloué au programme, si c'est pas le système qui le lui attribue...
C'est très mystérieux tout ça pour moi... Ouin bouh snif je ne serai jamais programmeur système

Oui et donc ça veut dire que quand un prog crashe, il laisse un fantome qui encombre la mémoire jusqu'au prochain redémarrage, c'est bien ça?
c'est toujours bon à savoir... On comprend mieux pourquoi ouindose apprécie tellement un petit redémarrage de temps en temps...

Mais je ne comprend pas d'où viens l'espace mémoire (on dit le heap je crois) alloué au programme, si c'est pas le système qui le lui attribue...

bah si c l' OS qui le lui attribue. c le taf du noyau, du kernel

ensuite une fois le programme mis en memoire par l' OS, le prog s'autogère...

Oui et donc ça veut dire que quand un prog crashe, il laisse un fantome qui encombre la mémoire jusqu'au prochain redémarrage, c'est bien ça?

oui plus ou moins. ce que windows peut liberer il le fait, il s'ameliore bcp de ce cote là

pis ya aussi le phénomène de fragmentation mémoire qui oblige a faire reset parfois.