[ Précédent :: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 :: Suivant ]
Contest
http://netbsd.org/Changes/#newlogo(...)
Over 400 logos were submitted by 238 artists for a NetBSD logo contest
les autres devaient etre TRES moches :-)
[ Répondre ]
Re: C'est plus possible
Non pour moi un fichier texte c'est un fichier qui contient de l'ASCII ou l'encoding que tu veux qui peut s'ouvrir avec n'importe quel editeur de texte. Mais certainement pas un tas de données binaires necessitant l'application adequat pour etre ouverte.
Un fichier texte ca se manipule avec cat, grep, awk, sed, perl, des pipes, des redirections de flux etc.
Ta solution est pire que le mal !
[ Répondre ]
Re: concrètement ?
> relire la référence ( http://ccs.ucsd.edu/c/lib_over.html#program%20termination(...(...))
Ca n'a rien a voir. La recuperation de la mémoire ne depend pas du runtime du C mais du noyau. Quand un processus est créé par le noyau il créer un nouvel espace d'adressage pour le processus, appel le point d'entrer du programme via le loader (le point d'entré n'est pas le main en réalité y'a du code avant) qui lui même appelera main() si tu as un programme en C.
De même quand ton processus est detruit le tu sors du main(), il y a encore du code qui s'execute dont tu n'as pas connaissance et enfin l'ordre est donné au noyau de détruire le processus et au passage son espace d'adressage.
Tout les OS "modernes" courant reposent plus ou moins sur ce principe. Et tout le support est fournit pas le processeur pour y arriver facilement. Le fait que ton programme ou ton runtime C libere la mémoire que lui a attribue le noyau n'a rien a voir, ce sont deux concepts différents (cf dans beaucoup d'OS le tas ne peut que grossir même si tu free() toute ta mémoire...)
Donc pour trouver un système qui ne libère pas la mémoire il faut au choix
- trouver un noyau avec un VM completement buggé (mais ca devient grave !)
- peut etre chercher du cote des systemes pour les processeurs sans MMU
- avec MMU dans l'embarqué mais meme la ca m'étonnerait
- En regardant du cote de windows 9x et OS 7..8..9 on doit pouvoir trouver des conditions dans lesquels la mémoire n'est pas libérée mais de toute facon on peut faire a peu pres n'importe quoi :-)
http://developer.apple.com/documentation/mac/Memory/Memory-2.html(...) C'est rigolo de voir l'état de la gestion mémoire d'OS 7
[ Répondre ]
Re: OS
> je me sens vraiment comme un vieux con
Si tu codes en objet c'est normal, effectivement la construction des objets et l'archi globale des applications fait que tu es beaucoup plus carré de ce coté la.
Si tu regardes du cote du C (puisque c'est principalement lui qui pose problème) j'ai jamais vu un devel ecrire "propre". Si tu fais un valgrind sur les applis tu verras qu'il n'y a pas de leaks simplement des warnings "Memoire encore referencee mais non liberee" par ce que ca valait pas le coup de saloper le soft de code inutile. La ou c'est propre dans des destructeurs et se fait en 80 caracteres en P0O; en C tu auras souvent un pavé de 50 lignes pour reussir a terminer proprement, donc on ne fait que ce qui est necessaire et en utilisant atexit() par exemple.
Genre tu ecris un filtre qui construit un arbre a partir de stdin et qui en fait XXX sur stdout. 99% des devels ne vont pas libérer la mémoire, il leur suffirait de faire un parcours recursif s'il y avait besoin mais tant que le cas special ne se presente pas.... Si le même devel est en train d'écrire une lib qui s'interface sur graphviz il fera une fonction pour libérer sa structure.
[ Répondre ]
Re: OS
T'arrives pas a comprendre la différence entre maitriser a tout instant ce qui est alloué mais volontairement ne pas s'emmerder a faire des liberations que l'on sait ne servir a rien (typiquement si ton cgi construit une liste chainee qui te sers durant une grande majoritée du temps d'execution) et coder comme un con et ne pas savoir gérer sa mémoire ?
Le "il faut pas le faire *jamais" est aussi stupide que le mec qui ne comprend pas qu'il fait mal pour moi. C'est a toi de savoir ou c'est important et ou ca l'est pas. Tu _maitrises_ ton code, son environement et les parametres que tu souhaites optimiser et tu codes en fonction de ca. Evidement tu codes pas de la même manière si tu bosses sur de l'embarqué sur un proc sans MMU, que lorsque tu ecris un filtre UNIX, ou une usine a gaz de 10 000 000 de lignes de code !
Note: personne n'a contesté jusque la que perdre les references sur de la mémoire allouée était une erreur monstrueuse !
[ Répondre ]
Re: C++
Tu peux bien ecrire des drivers I/O en (un sous ensemble du) C++ via l'I/O kit.
XNU pour lui est du C pur et dur.
http://developer.apple.com/documentation/DeviceDrivers/Conceptual/I(...)
http://developer.apple.com/documentation/Darwin/Conceptual/KernelPr(...)
Pour ce qui est du C++ dans le noyau je crois que linus a deja dit ce qu'il en pensait dans le passe :
http://kerneltrap.org/node/view/2067(...)
Je lis plus lkml mais je pense pas que son avis soit beaucoup différent maintenant...
[ Répondre ]
Re: esd suxor des ours népalais...
Et quand tu as retiré ce qui sert pas dans tout les cas d'utilisation différents de linux il te reste les repertoires kernel/ fs/procfs/ et mm/ (quoi que on doit pouvoir trouver un patch pour systeme sans MMU)... Avec ce raisonement on va avancer vite ou alors a tout passer en userland linux va devenir un micronoyau avant que Hurd soit sorti !
Dis moi tu connais les modules noyaux et la recompilation pour adapter l'outil a ses besoins ?
Autrement FreeBSD (au hasard) qui est bien connu pour être un OS uniquement destiné au desktop ne pose aucun probleme de ce cote la depuis.... oula je sais meme plus
[ Répondre ]
Re: Mauvais débat.
s/tas/pile/
Je parlais dans le cas ou tu termines l'execution... C'est sur que c'est tres grave le delete manquant dans un espace d'adressage qui va etre detruit dans la seconde :-)
Si ton appli a fait son job apres tu t'en fou le système est la pour ca d'ailleur dans tout les softs que j'ai lu (ok je code en C) j'ai pas croisé souvent de gens qui avaient de bonnes habitudes...
Apres j'ai pas lu le thread de fclc++ et je m'en fou donc je n'ai pas repondu la premiere fois en connaissant le contexte (relire mon post).
[ Répondre ]
Re: Mauvais débat.
> Là, je n'ai pas de réponse mais je pense que oui de plus en plus.
Heu comment dire tu sais comment fonctionne les VMs ? :-)
> J'aimerai urler : NON, PAS DE FUITE DE MEMOIRE, c'est crade au possible et ca montre qu'on ne maitrise pas ce que l'on fait.
Ce n'est pas une fuite mémoire. Une fuite c'est que tu perds toutes les references sur la memoire que tu as alloué. La effectivement c'est une erreur de conception et c'est a corriger.
Ne pas liberer la mémoire avant la terminaison de l'execution c'est eclaircir le code et une "optimisation"
if (xxxx)
exit(1);
C'est un tantinet plus propre qu'un
if (xxxx) {
/* 45 lignes pour desallouer toute la memoire allouee */
exit(1);
}
C'est exactement la meme chose et c'est meme plus rapide ! (liberer toutes les vmas d'un processus est un tantinet plus rapide que 47 540 free())
[ Répondre ]
Ca depend
Ca depend du contexte :
-> Si il parle de pas s'emmerder a chercher tout ce qui est alloue justement avant d'appeler exit(0) ou quelque chose du genre il a raison
-> Si il parle en general c'est moins top
C'est dans quel thread ?
[ Répondre ]
Re: Le contenu, le contenu...
> y'a t'il des logiciels permettant de voir ce que verrait un daltonien ou autre ?
http://wellstyled.com/tools/colorscheme2/index-en.html(...)
> Selon moi le Flash n'a pas sa place sur le web,
http://www.redbullrampage.com/(...)
Limiter au maximum son utilisation ok, dire qu'il n'a pas sa place c'est aller un peu loin. (cf yetisport aussi :-) on peut faire des choses pratiques avec, c'est comme pour tout il faut choisir le bon outil pour la bonne tache
[ Répondre ]
[ Précédent :: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 :: Suivant ]
Cette page a été générée par Templeet en 0.0931s (dont 0.0159 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Autoroutes
> je prefere les Nationales gratuites et sures qu'aux autoroutes payantes et dangereuses (pas d'eclairage, trop de camions).
C'est bien connu que les nationales sont eclairees !
Ha oui au fait, si on fait un bete calcul nb accidents graves/km, les nationales ont plus de deux fois plus d'accidents...
[ Répondre ]