Reprise du message précédent :

C'est inutile ici, mais il vaut mieux prendre de bonnes habitudes des le depart: desallouer tout ce qui n'est pas recupere par le programme.
Faire confiance a l'OS peut reveler des surprises...
D'autre part, une fois que c'est bien ecrit, et sans bug connu, tu peux dans une phase finale d'optimisation, virer une telle desallocation si tu sais que le systeme y retrouvera ses petits.  
Mais il faut toujours passer par une phase initiale ou l'on sait desallouer ce qui l'a ete (et pas que pour les allocations memoires; pour les fichiers ouverts et non fermés, les ressources systeme (ca s'est ameliore sous windows de nos jours, et j'ose esperer que c'est maintenant le cas sous MacOsX), etc.)
A+,

Tout à fait d'accord.
 
Pour ce qui est de variables de type "simple", on n'a pas de problème de désallocation.
 
Mais dès qu'on utilise des objets qui peuvent avoir des interfaces assynchrones ou inter-agir avec d'autres systèmes, il est impératif de fermer proprement les objets, puis les désallouer.
 
Le meilleur exemple que je connaisse sous Windows, c'est la couche ADO, qui permet d'inter-agir avec des bases de données.
 
Lorsque tu crées un tel objet, Windows lance un process indépendant de ton programme, qui va gérer un pool de connection à ta base. C'est ce dernier qui va gérer l'accès à ta base, et surtout partager les ressources entre plusieurs programmes qui accèderaient à la même base.
 
Il y a quelques temps, depuis un site web, avec une page ASP, je lançais une transaction sur la base de données.
Et je me suis pris une erreur que je ne trappais pas.
Il en a résulté que mon prog a planté sauvagement. Malgré le garbage collector de la couche WSH de Windows, et celle de IIS lui-même, ma connection à la base (avec la transaction) est restée active.
 
Résultat, c'est tout un ensemble de lignes qui sont restées indisponibles dans la base de données (Oracle) pendant plusieurs minutes, le temps que la transaction entre en time-out.
On peut aussi avoir le problème avec un fichier ouvert. Généralement, ce genre de problèmes ne survient que lorsque le programme est quitté inopinément. Mais il arrive que même lorsque tu quite normalement le programme, certains objets ne sont pas détruits. Outre la "fuite mémoire" occasionnée, le plus gros risque provient des ressources éventuellement utilisées par cet objet, qui restent inaccessibles tant que ce dernier n'est pas arrêté.
 
Donc, même dans les langages évolués, dottés d'un garbage collector, qui est censé gérer ça, il est très fortement recommandé de libérer à la main les ressources, quelles qu'elles soient, car c'est en ayant de bonnes habitudes qu'on risque le moins d'oublier un jour un endroit où c'était nécessaire.

par pitié arrétez les casts !

 
pardonne leur, ils ne savent pas ce qu'ils font...
 
Plus sérieusement, dans beaucoup de docs que j'ai vu ils font les casts...

Taz, la j'ai ecrit ecrit du C, or en C, caster un malloc sur le type pointé est la pratique habituelle.
A+,

Ben oui enfin c come ca qu'on nous l'apprend en tout cas

Okkk merci de ton explication

de même que while(!feof, fflush(stdin), ne pas initialiser un pointeur, utilisez scanf directement, utilisez gets, les nombres magiques, ne jamais vérifié les codes d'erreurs, etc
 
faut arrêtez les mecs avec vos casts, ou alors il faut aller au bout de votre raisonnement et en mettre systématiquement sur chaque conversion
 
surtout que les cast a outrance provoquent des erreurs (voir le sujet sur le type punning) et le cast au retour du malloc est publiquement déconseillé sur toutes les FAQ.
 
bon pour ceux qui réfléchissent un peu quand ils codent, je rappelle qu'en C, les conversions Type* <-> void* sont implicites car parfaitement légales et au comportement sur.

je crois que c'est l'argument type : si je vous voulez que je vous laisse faire ce qu'on vous apprend, je repars définitivement

adieu  

Decidement tu as rien pigé Taz!
Les casts sur un malloc en C, c'est un dialecte, le plus courant d'ailleurs.
Ca sert a rien, sauf a une chose: a rappeller a la lecture le type de ce qui est alloué.
Parce que sur un petit exemple a la con, c'est sur que c'est inutile, mais quand tu as des milliers de lignes de code (ou des millions de lignes de codes avec des centaines de fichiers ou sont definis tes types), ca aide a la lecture du source.
C'est pas un hasard si les programmeurs C utilisent cette convention implicite depuis des années.
Cantonnes toi donc au C++ que tu as l'air de tres bien connaitre, au lieu de critiquer le C sans manifestement te rendre compte que tu es a coté de la plaque.
A+,

c'est toi qui n'a pas compris que le typage est inexistant avec la mémoire allouée dynamiquement en C.
ce que tu dis c'est la meme chose que int i=(int)42; par ce que « ça me rappelle quelque chose. »
 

bien au contraire. va dire ça au mec le jour ou il y a un changement de type ou de nom de type. la syntaxe canonique pronée par tout les gens de bonnes volontée (commité ISO compris) est
 
T *p = malloc( sizeof *p );
 
la conversion est implicite, et malloc renvoie une zone mémoire correctement alignée. l'allocation mémoire n'a rien à voir avec le typage ou autres informations
 
[/citation]

mais bien sur. je maîtrise aussi bien le C que le C++, le C étant plus simple, j'en connais très bien les règles.

Que tu maitrises la syntaxe du C je n'en doute pas.
Que tu maitrises le travail en equipe sur des projets en C de millions de lignes, au vu du type de commentaires que tu as ici posté, permet moi d'emettre un doute.
A+,

... continuez à écrire des trucs inutiles, dormez tranquilles vos compilateurs sont contents, soyez en paix, si les gens font comme ça c'est toujours parce qu'il y a une explication rationnelle ...

Truc inutile pour le programme en tant que tel, mais pas pour qui relit le code...
Et c'est une question de culture (celle des programmeurs C en l'occurence). Depuis quand les notions culturelles se doivent d'etre rationelles??
Si c'etait le cas, il n'y aurait qu'un seul style d'ecriture de blocs, le style
if (...) {
    ...
  }
qui a ete montre comme plus efficace (par des psychologues-ergonomiciens) que le style
if (...)  
  {
     ...
  }
 
A+,

rien à voir.
les trucs "je cast partout" génère des erreurs et reflètent l'incompréhension la plus totale du système de typage. encore une fois, va voir le sujet sur le type punning et comprends bien que caster quand il ne faut pas, quand il n'y en a pas besoin créer plus d'erreurs que ça n'en résout ( ==0 )

pour vous départagé :

Je pense que le noyau linux 2.4.23 est un bon gros projet ce pendant on voit bien que les allocation mémoire ne sont pas castée.

1) On a pas parlé de cast partout (je me repete, là, a croire que tu ne lis pas mes reponses), mais du cast sur un (m/c)alloc.
2) On ne parle pas de comprehension du systeme de typage, mais d'aide a la relecture de code en utilisant un dialecte qui s'il est inutile au programme, aide a la relecture, dans un cas precis.
3) J'ai jamais dit le contraire; ce que j'ai dit, c'est que changer les habitudes de programmeurs d'une equipe ou melanger plusieurs style d'ecriture dans un meme source est encore plus generateur d'erreurs, et qu'entre deux maux, on choisit le moindre.
 
Bon, la je vais plus etre present pour polemiquer, c'est l'heure de mon train.
A+,

bah paul c'est moi mais c'est qui mickey ?
 
 
 
je suis sortis  

1) qui est le cast tu plus inutile et source d'erreur que l'on connaisse. lever le bras ce qui cast le malloc et ou blie le #include <stdlib.h>, ça compile sans rien dire et boum ...
2) bas je vais tout caster, chaque usage de variable, je me relirais mieux comme ça. tu te rends compte de ce que tu dis ? les casts ont expres une syntaxe hideuse pour dissuader les gens; tout ça est ridicule.
3) et bien ici, je donne des conseils tenus pour bon et valides

l'es pourri ta blague, noir désir  l'a faite dans "un autre jour en france" y a des années

et ?
j'ai jamais dis que je l'avais inventé ni quelle etait bien elle à juste pour but de détendre l'atmosphère que je juge un peu tendu pour un post qui à déjà eu ca réponse

moi je suis pépère là, je me tiens comme Al bundy, je bois du coca (autre génération), etc

pourtant tu semble pas vraiment détendudétendu ...
(non je veux pas savoir si c'est détendu ou pas)
oublie ce que j'ai dis...

ben si, je suis détennedu, daitainedu

Oh ben je vois que j'ai foutu la m**de avec mes questions!
bon je pense que j'vais quand même continuer à caster mes allocations dynamiques (dzl Taz) en fait t'as surement raison mais bon mon prof ne l'entend pas comme ca, et c'est lui qui me note donc...
Taz tu bosse dans le développement ?
 
a+

voilà faites plaisir aux profs et aux compilos. les bugs C coutent des milliard d'euros tous les ans à cause d'enseignants incompétents et ignorants, mais comme c'est eux qui détiennent le savoir, ben ils  ont forcément raison. droit dans le mur les mecs.
je suis étudiant en maîtrise.
 
si t'as des problèmes avec ton prof qui te fout une mauvaise note à cause de ça, tu va le voir avec ton K&R sous le bras, et là en te voyant arriver avec ce livre qu'il n'a sans doute jamais lu, il va changer d'avis après lecture de l'ouvrage des créateurs du C.

bah dis toi qu'un prof ne te mettras pas une mauviase note si ton prog compil et marche (apaprt notre prof de compil mais il est con lui c'est pas pareil il lit meme pas le code et ne lit que le rapport)
tout ca pour dire que si tu fais de vrai C tu ne peux pas avoir une plus mauvaise note qu'un mec qui fait apreil que toi mais en faux C.

C'est vrai que 90% du code existant cast le retour de malloc. Les développeurs le font pour faire taire les warnings du compilo, sans comprendre ce que signifient vraiment ces warning. Mais c'est très dangereux.
 
Example concret : la plupart des développeurs oublient d'include <stdlib.h>, qui contient la déclaration de malloc. Ca compile quand même, avec cette différence cependant que le compilo considérera que malloc renvoie un int au lieu d'un pointeur, comme toute fonction non déclarée. Si tu ne cast pas tu aura un beau warning à cause de la conversion (int -> void *). Si tu cast le warning disparait, et tout le monde est content... Sauf que si tu compiles ton prog en 64 bits alors Boom ! Tu initialises ton pointeur (64 bits) avec un int (32 bits en géneral). Ca fait un drôle de pointeur...
 
Bref les casts inutiles, c'est super dangereux.

Si tu as envie de troller, ca te regarde.
A+,

tu veux pas plutôt laisser les gens apprendre et donc mieux maîtriser le C au lieu de nous les briser ?
aujourd'hui, si tu apprends le C par toit même avec un vrai bouquin, tu ne verras aucun de ces casts à la noix. je vois pas pourquoi on devrait se trimbaler éterellement les erreurs de générations de programmeurs C. Ffluff à fait la preuve que des logiciels de qualité sont programmés purement

 
Euh non. Pas les programmeurs C avec de la bouteille.  
D'autre part, un grand nombre de programmeurs C ont programmé en utilisant pendant des années des compilateurs non iso pour diverses raisons, en particulier sur certains Unix. Or dans la periode pre-iso, le cast etait necessaire. Bon, depuis la generalisation de l'emploi de compilos iso on aurait effectivement pu changer de dialecte (surtout qu'a cette occasion il a fallu reecrire les declarations de fonctions avec les parametres types dans les parentheses et non apres, ainsi que les prototypes), mais les habitudes acquises ne s'oublient pas  si facilement, d'autant que la seconde edition du Kernighan & Ritchie preconisait toujours ce style [meme si de nos jours, sur leur page d'erratas, ils conviennent qu'il faudrait reformuler cette phrase, mais qui lit les erratas]
A+,

De nos jours, je vois plus trop l'interet d'apprendre le C, mais c'est un autre sujet.
A+,

Le C est fait pour la programmation système.
Donc toutes personnes voulant faire de la programmation au niveau système a plus de chance d'y arrivé si elles programment en C.

 
J'prends peur là !!!
 
bizarre facon d'utiliser tes structures
 
pour un objet
 
pile p;
p.fonction();
 
pour un pointeur sur un objet
pile * p;
p->fonction();
 
mais pas (*p).fonction(), ca c'est pas beau

La probabilité est-elle plus forte avec Ada ?

La programmation systeme ne va t'elle pas migrer petit a petit vers C++ (ou dans certains cas, du C compatible C++ et compile par un compilo C++), vu la performance des compilateurs moderne?
Dans le cas des systemes embarqués, je n'ai pas d'opinion, vu que je connais assez peu le domaine.
De toute facon, mon post initial se referrait plus au fait de qqu'un qui fait de l'info actuellement a majoritairement des chances de faire soit de l'applicatif, soit de l'integration d'applicatif, et que C n'est plus (IMHO) le meilleur langage pour ce faire.
A+,

IMHO ?

In My Humble Opinion

Perso, je préfère :
 
if (...)
{
    ...
}
 
C'est d'ailleurs l'indentation par défaut proposée dans la plupart des ide.

Perso, préfère le  
if ( ) {
   ...
} else {
   ...
}