Compilateur oncalc - Page 2

./29: Mais non. C'est

PpHd :
./29: Mais non. C'est

Non, c'est une pratique de programmation très discutable ... Même sous un OS qui récupère automatiquement les ressources après exécution.

Oui, prenons exemple sur les Amiga. A bas le resource tracking.

Billy Charvet :
Oui, prenons exemple sur les Amiga. A bas le resource tracking.

Le resource tracking est une bonne chose pour un OS (je dirais même que c'est essentiel pour qu'un OS puisse être qualifié de robuste). Cependant, le programmeur doit se faire un devoir de libérer les ressources qui cèssent d'être utilisées au cours de l'exécution de son programme, c'est plus élégant et même nécessaire sur les systèmes qui ne réclament pas automatiquement les ressources à la fin de l'exécution d'un programme.

Pourquoi dupliquer les taches ? Si quelqu'un fait une chose, pourquoi devrais-je le faire aussi ?

PpHd :
Pourquoi dupliquer les taches ? Si quelqu'un fait une chose, pourquoi devrais-je le faire aussi ?

Pour un OS : Parce qu'on n'a aucune garantie que tous les programmes sont leak-free. Un os ne peut être robuste (e.g. DOS ou Win 9x) s'il permet qu'un programme laisse des locks derrière lui.

Pour un programme : De nos jours, il est vrai qu'on a beaucoup de mémoire, mais ce n'est pas le cas de toute les autres ressources. La principale raison est donc l'élégance, je vous l'accorde : c'est une question d'éthique avant tout. Sur un système plus limité c'est une question de nécessité, car on peut plus facilement crasher par manque de RAM si le programme est trop exigent.

Martial Demolins :
On pourrati toujours dire qe vu que PreOs le fait, c'est de la perte de RAM que de le faire à la main dans un programme kernel, non?

oué ben cross ^^

C'est de la perte de RAM un call de fonction VS un GOTO, non ?

C'est plus portable si on libère manuellement(vu que tous les systèmes ne gèrent pas ça). De plus c'est une habitude à prendre car dans certains cas il faut libérer un ressource des qu'on en a plus besoin pour limiter l'utilisation memoire en cours d'execution.

C'est de la perte de RAM un call de fonction VS un GOTO, non ?

Je sais pas mais en général ca fait plusieurs romcalls.

>C'est de la perte de RAM un call de fonction VS un GOTO, non ?
Houla. Ca n'a rien a voir

>De nos jours, il est vrai qu'on a beaucoup de mémoire, mais ce n'est pas le cas de toute les autres ressources.
De toute facon, avec Java, ce n'est plus un probleme

PpHd :
>C'est de la perte de RAM un call de fonction VS un GOTO, non ?
Houla. Ca n'a rien a voir

En fait si. J'exprimais que le fait qu'une alternative prenne plus de RAM ne la rendait pas de facto caduque.

PpHd :
>De nos jours, il est vrai qu'on a beaucoup de mémoire, mais ce n'est pas le cas de toute les autres ressources.
De toute facon, avec Java, ce n'est plus un probleme

Effectivement, parce que Java s'en charge.

Martial Demolins :
>De toute facon, avec Java, ce n'est plus un probleme
Serait-ce un troll??

De toute façon, sur TI le 'java' n'est pas GC.

Se reposer sur le kernel pour nettoyer les memory leaks est pragmatique. Mais ça serait beaucoup mieux si tout le monde pouvait utiliser le programme (= AMS native) et qu'il ne faisait pas n'importe quoi à la moindre occasion. Peut-être que ça lui supprimerait des bugs, d'ailleurs (pas de kernel = moins de RAM prise => moins de risques de Out of memory).

Ne te fatigue pas, c'est un troll de puis le debut

FI, il existe une routine de décompression très rapide pour le PPG (~70-90 KB/s). Evidemment, [size optimization extremist] a mis la version optimisée taille extrémiste, qui est plus lente que la version précédente, dans les lanceurs spécifiques de TIGCC 0.96 (qui ne servent, on le sait bien car c'est un fait, qu'à bouffer de la place, comparé à un lanceur générique, dès qu'il y a plus de deux tels lanceurs spécifiques).
Mais il n'existe actuellement pas de moyen optimal d'utiliser la routine rapide (elle compile sans problème avec ttstart générique en C, mais ttstart générique en ASM refait à partir du pstarter n'est pas encore fait)...

PpHd :
Ne te fatigue pas, c'est un troll de puis le debut

Quoi ? Vous me trollez ?

Les OS ne devraient pas faire de resource tracking.
Les programmes devraient avoir été bien conçu du départ,
et c'est tout.

Car un OS actuel ne peut se fier aux programmes et fait du resource tracking.
Et les programmes ne peuvent se fier aux OS, et libèrent manuellement.

Donc pour être sûr qu'il n'y aura aucun problème, on doit l'implémenter - et on l'implémente
effectivement - dans l'OS et dans les programmes.

Ce qui ralentit l'exécution. La gestion du resource tracking ou un free() peut paraître
mineur, mais quand on pense à tous ceux qui vont être exécutés lors de l'utilisation
de l'OS, ça devient différent.

Un OS ne devrait pas le gérer, mais fournir un programme pour repérer les fuites mémoire.
Ca obligerait les programmeurs à bien coder directement. Et ça marcherait bien partout,
c'est sûr.

D'un autre côté utiliser le resource tracking est plus simple. Alors on pourrait compter dessus,
et oublier tous les free() et autres routines de libération.
Ca peut même paraître une meilleure solution, car elle est plus flemmarde, mais
soit on aura moins de contrôle du côté du programmeur, - quand on veut libérer une
ressource parcequ'on a pas une mémoire illimitée. -
On ne pourra pas désallouer explicitement comme avant.
Il faut modifier free() de manière à ce qu'elle court-circuite le resource-tracking
, elle libère MAIS elle annule la libération automatique... --> free() devient plus lente...

Et pour la libération des ressources non désallouées explicitement, soit on va faire
une routine neuve, d'où des doublons dans le code, soit on va utiliser free(). Qui elle-même
enlève à chaque fois la ressource de la liste des ressources à libérer.

Maintenant, on fait ça sur un système qui fait ça sans arrêt. Multi-tâches, à grande échelle,
utilisant le C++, beaucoup de ressources dynamiques... on perd de la vitesse.

Et ça demande d'avoir parfaitement confiance en l'OS. Si il y a un problème où que ce soit
du style l'erreur bête qui arrive tout le temps, pas assez d'optimisation sur free(), on va
VRAIMENT en baver pour se débarasser d'une ressource, par rapport à un système simple
où tout repose sur nos épaules.

certes, c'est plus rapide, mais ça reste toujours plus lent qu'un truc pas compressé du tout

Cross...

./50 >

Les OS ne devraient pas faire de resource tracking. Les programmes devraient avoir été bien conçu du départ, et c'est tout.

Mais oui Quelle idee geniale !
Sauf que 90% des programmeurs sont des gros nuls qui ne comprennent meme pas ce qu'il font

Car un OS actuel ne peut se fier aux programmes et fait du resource tracking.
Et les programmes ne peuvent se fier aux OS, et libèrent manuellement.

Je n'ai pas confiance en toi. Tu n'as pas confiance en moi. Nous n'avons confiance en personne.
En fait, pouvons nous nous fier au processuer ?

Donc pour être sûr qu'il n'y aura aucun problème, on doit l'implémenter - et on l'implémente
effectivement - dans l'OS et dans les programmes.

Se peut-il ?

Ce qui ralentit l'exécution. La gestion du resource tracking ou un free() peut paraître
mineur, mais quand on pense à tous ceux qui vont être exécutés lors de l'utilisation
de l'OS, ça devient différent.

elle est mineure, ou mal concus.
Le probleme est plutot du cote de la fragmentation.

Un OS ne devrait pas le gérer, mais fournir un programme pour repérer les fuites mémoire.
Ca obligerait les programmeurs à bien coder directement. Et ça marcherait bien partout,
c'est sûr.

Il existe des outils de developpement pour

D'un autre côté utiliser le resource tracking est plus simple. Alors on pourrait compter dessus,
et oublier tous les free() et autres routines de libération.
Ca peut même paraître une meilleure solution, car elle est plus flemmarde, mais
soit on aura moins de contrôle du côté du programmeur, - quand on veut libérer une
ressource parcequ'on a pas une mémoire illimitée. -

Rien n'empeche d'utiliser les deux

On ne pourra pas désallouer explicitement comme avant.

Il faut modifier free() de manière à ce qu'elle court-circuite le resource-tracking
, elle libère MAIS elle annule la libération automatique... --> free() devient plus lente...

huhu

Et pour la libération des ressources non désallouées explicitement, soit on va faire
une routine neuve, d'où des doublons dans le code, soit on va utiliser free(). Qui elle-même
enlève à chaque fois la ressource de la liste des ressources à libérer.

Bah. On est plus a un doublon pres.

Maintenant, on fait ça sur un système qui fait ça sans arrêt. Multi-tâches, à grande échelle,
utilisant le C++, beaucoup de ressources dynamiques... on perd de la vitesse.

Moins qu'a installer Windows qui lance ces routines d'auto-espionnages integrees.

Et ça demande d'avoir parfaitement confiance en l'OS. Si il y a un problème où que ce soit
du style l'erreur bête qui arrive tout le temps, pas assez d'optimisation sur free(), on va
VRAIMENT en baver pour se débarasser d'une ressource, par rapport à un système simple
où tout repose sur nos épaules.

Confiance en l'OS ?

Un petit troll. Rien de tels pour s'occuper pendant un bench

Mais oui Quelle idee geniale !
Sauf que 90% des programmeurs sont des gros nuls qui ne comprennent meme pas ce qu'il font

Oui.

Je n'ai pas confiance en toi. Tu n'as pas confiance en moi. Nous n'avons confiance en personne. En fait, pouvons nous nous fier au processuer ?

Non, mon Athlon ne veut plus rien faire à 35 degrés, une température
qui ne va pas tarder d'ailleurs.

elle est mineure, ou mal concus. Le probleme est plutot du cote de la fragmentation.

Oui, on peut aboutir à ces problèmes de free PLUS un malloc
mal foutu (ce qui est vraiment plus courant en effet).

Il existe des outils de developpement pour

Ben c'est là que je veux en venir. Pour les fuites mémoires,
il existe des outils de developpement pour, le resource tracking ralentit le système pour faire attention aux mauvais programmeurs.

Rien n'empeche d'utiliser les deux

Si: c'est plus lent. Et si on fait des choix sur cette logique
chaque fois qu'on a à faire des choix en informatique, on
a besoin d'une station SGI pour bosser. lol

Non je déconne c'est vrai qu'on utilise les deux et que ça change
pas grand'chose, mais c'est le principe de ce choix, négligeant
la rapidité, que j'aime pas.

huhu

héhé

Bah. On est plus a un doublon pres.

Maintenant, on fait ça sur un système qui fait ça sans arrêt. Multi-tâches, à grande échelle, utilisant le C++, beaucoup de ressources dynamiques... on perd de la vitesse.

Moins qu'a installer Windows qui lance ces routines d'auto-espionnages integrees.

Ouiiii... lol

Confiance en l'OS ?

C'est pour ça que je me plains.

PpHd :
Un petit troll. Rien de tels pour s'occuper pendant un bench

Bon, pour en revenir à SIDE et à CC.

Pour CC :
où puis-je trouver la version non ppg (La décompression me saoule profondément...) ?

Pour Side :
Je suis d'acdcord avec PpHd pour dire que les niveaux de gris, ca rend la source illisible, je préfere donc sa version.
Seulement, y a un bug, un bug crétin et qui m'a particulièrement énnervé...
Dans les options, on peut regler l'appel du compilateur et l'appel du programme lui même.
Pour le compilateur, par défaut, c'est as("!","!_c"). J'en ai donc déduit que Side remplacait ! par le nom du fichier source lors de l'appel du compilateur. Seulement, j'aimerais remplacer ca par : isocc("!","!c"). Et c'est là qu'on se rend compte de la coquille (enlevez le q...) : il n'y a aucun moyen, dans les options, de taper le caractere ! qui ser trouve normalement dans la table de carracteres.
Avouez que, comme bug, c'est assez con !

Heu...
Sur 89, essaye diamand + '/' (Touche diviser)
Sur 92+/v200, essaye [2nd] + w

Ca marche sur pedrom au moins

Pour CC prends la version kernel, elle est non ppg. et tu éviteras en plus les fuite de memoire en cas de certaines erreur.

wow wow wow... oubliez pas de rajouter quelques smileys des fois (pphd, billy charvet, etc...), on pourait presque penser que vous vous croyez au-dessus d'une masse là, heureusement c'est pas le cas, hein ?