C'est si beau de gérer les cas d'erreurs au lieu de coder comme un porc
au moins un
if(!machin) return SOME_ERROR_CODE;
c'est une question de qualité minimale.
Ou bien class Exception { };
class OutOfMemoryException : public Exception { };
void* mymalloc(size_t size)
{
void* result = malloc(size);
if (result) return result;
else throw new OutOfMemoryExcepti(Oui bon, en pratique il faut mettre en cache l'exception pour ne pas avoir à utiliser de new…)
(avec du code et des macro qui vont bien ^^)Brunni (./11243) :Bah non. Dans un des mes programmes, j'ai fait, par erreur, un malloc de 40 Go, au lieu de 4 Go, et ça me l'a refusé et heureusement
Ben pour qu'un malloc soit refusé il faut avoir désactivé la swap
Zerosquare (./11244) :
Perso au minimum c'est assert(ptr != NULL), sachant qu'effectivement ça va planter brutalement s'il n'y a pas assez de mémoire, mais au moins ce sera un plantage traçable. Entre ça et un comportement indéterminé, franchement, le choix est vite fait...
Pen^2 (./11252) :J'ai dit "au minimum", donc c'est plutôt pour des programmes persos. Et je ne fais quasiment pas de softs PC "pros", donc la question se pose rarement
tu laisses tes asserts en release ?
Zerosquare (./11244) :
Je vois pas ce qu'il y a de con à désactiver le swap... ce qui est plutôt con, c'est qu'il y a des cas où ça apporte un gain de performance de le faire !
Et pour le malloc(), je te croyais plus rigoureux que ça quand même
Perso au minimum c'est assert(ptr != NULL), sachant qu'effectivement ça va planter brutalement s'il n'y a pas assez de mémoire, mais au moins ce sera un plantage traçable. Entre ça et un comportement indéterminé, franchement, le choix est vite fait...
Zerosquare (./11244) :
Je vois pas ce qu'il y a de con à désactiver le swap... ce qui est plutôt con, c'est qu'il y a des cas où ça apporte un gain de performance de le faire !
Brunni (./11259) :Ben oui, je me place dans le cas où il y a suffisamment de RAM physique pour tout faire rentrer (sinon, c'est sûr que sans swap ça va coincer
Ce n'est pas une bonne idée de le faire, c'est tout. Ou alors tu as assez de RAM pour que la limite de malloc n'existe virtuellement pas pour les applications que tu utilises.
). Mais le fait est que sur certaines machines où c'est le cas, Windows (et peut-être d'autres OS) a de meilleures perfs avec le swap désactivé qu'avec le swap activé, ce que je considère comme un défaut de conception. À plus forte raison quand ça plante carrément si on vire le swap.Brunni (./11259) :C'est que l'OS et/ou les applis sont mal codées, c'est tout. Déjà un système embarqué ne devrait pas planter comme ça. Ensuite, pour se retrouver à court de RAM à ce point, soit c'est mal géré, soit ils ont été radins sur la quantité de RAM. Rajouter du swap est une fausse bonne idée (ça rame, et ça use les mémoires flash). Par ailleurs, y'a des trucs qu'on peut virer de la RAM sans avoir besoin de swapper (par exemple, le code inutilisé, qui peut être rechargé depuis le fichier exécutable).
Il n'y a qu'à prendre l'iPhone pour s'en rendre compte; la RAM est tout le temps pleine de choses inutiles, qui seraient bien mieux en swap. Résultat l'OS est tout le temps en train de libérer les vieux trucs, et quand il n'y arrive pas assez rapidement l'application en foreground plante. Ce n'est pas une vision très fiable de l'informatique.
squalyl (./11245) :
C'est si beau de gérer les cas d'erreurs au lieu de coder comme un porc
au moins un
if(!machin) return SOME_ERROR_CODE;
c'est une question de qualité minimale.
Brunni (./11259) :Zerosquare (./11244) :Ce n'est pas une bonne idée de le faire, c'est tout.
Je vois pas ce qu'il y a de con à désactiver le swap... ce qui est plutôt con, c'est qu'il y a des cas où ça apporte un gain de performance de le faire !
Folco (./11265) :
Euh...
J'ai 2 Go de RAM, je sais que je n'ai besoin que d'un Go, pourquoi ce serait con de le désactiver, sachant que Win le gère avec les pieds ? Je fais encore ce que je veux et pense être optimal pour ma machine sans être con quand même, non ?
(et là on parle de cas où malloc() raterait; si tu es si sûr que ça n'arrivera jamais avec tes 2 Go alors inutile d'y songer). Si un composant système a besoin de mémoire et qu'on ne peut pas lui en donner, alors ça *va* merder, aucune autre solution possible. Avec la swap pas. Et quand je vois un système planter pour ça, je me dis avant tout que l'utilisateur est con.), mais si on regarde par exemple le petit carré en bas à droite de ce screen:
Fichier joint : Fichier joint : Brunni (./11272) :
Oui, ben si tu crois mieux savoir que ton OS alors ne viens pas te plaindre si ça plante(et là on parle de cas où malloc() raterait; si tu es si sûr que ça n'arrivera jamais avec tes 2 Go alors inutile d'y songer). Si un composant système a besoin de mémoire et qu'on ne peut pas lui en donner, alors ça *va* merder, aucune autre solution possible. Avec la swap pas. Et quand je vois un système planter pour ça, je me dis avant tout que l'utilisateur est con.
Brunni (./11276) :Ouais, enfin, quand il plante parce que t'en as 11.5/12Go, il a eu le temps de voir venir, quand même, c'est pas comme s'il n'avait que 640ko... idem sur 4Go... d'ailleurs, je ne comprends même pas que le système ne soit pas prévu pour refuser proprement une allocation de mémoire à un programme, ou mettre une demande en attente, plutôt que se mettre à mouliner comme un fou en étant à ras la gueule, voire corrompre la mémoire. Bon, on devrait y arriver progressivement avec le sandboxing par application, mais il y avait probablement d'autres moyens moins barbares de faire ça, quand même...
Ca a peu de chances d'arriver parce que tu t'en rendras compte bien avant. Et le système sera plus à même de déterminer quel processus killer si tu as 7 Go / 4 utilisés que si tu en as 3.5 / 4 par exemple.
Brunni (./11272) :
Oui, ben si tu crois mieux savoir que ton OS alors ne viens pas te plaindre si ça plante
Brunni (./11281) :
En tous cas quand une ressource est refusée, il n'y a pas de miracle, c'est noir/transparent/moche
