Florent C. a écrit 505 commentaires

Je préfère la portabilité java.

Très bien, c'est ton droit. Je ne faisais que citer le pourquoi du comment de la taille des types dans le langage C.

Mea culpa.
Remplacer sizeof (unsigned) par sizeof (long).
Evidemment sizeof (unsigned) == sizeof (int).

Leur taille est donc dependante du compilateur et de la plateforme. Autant dire que c'est le bordel.

Non, c'est ainsi dans un souci de portabilité. Un programme C n'est pas prévu pour tourner dans une machine virtuelle, mais sur n'importe quelle architecture (s'il est programmé de manière portable, bien sûr).

Et comme la portabilité est la première raison d'être du langage C, c'est très bien comme ça.

Autre chose. sizeof renvoie une taille en byte. Vous me direz, "oui, et alors ?" ... Et bien le mot "byte" en anglais ne signifie pas "octet", mais multiplet. Un octet est un multiplet de 8 bits. En anglais, octet se dit octet. Et sur certaines machines, les bytes font 7 bits. Encore une fois, merci aux concepteurs du langage C de nous avoir simplifié la portabilité : on compte en bytes, et ça marche sur n'importe quelle machine.

Eh oui !!
La taille des types dépend essentiellement de ta machine, de ton OS, et de ton compilateur.
Par contre il y a des règles :
1/ sizeof (char) == 1
2/ sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (unsigned)
3/ un float est représenté selon la normae IEEE 755, et un double c'est la même chose, mais avec une précision double (donc deux fois plus d'octets)

Maintenant, si tu veux absolument savoir quelle taille il fait, tu dois le faire au runtime grâce à sizeof ...

Euh, je viens de le relancer, et, en fait, si, xaos est très très facile à utiliser ...

Pas très pratique à utiliser, mais il a le mérite d'exister ...
Sinon, tu peux peut-être regarder dans les filtres et script-fu de Gimp ...

Sûrement pour faire des map, et pour pouvoir changer des portions d'images avec des mouse-over, ou faire des petites animations ... Plein de possibilités ...

Je me suis dit la même chose que toi. Mais à la réflexion, ce qui est illégal, c'est de s'introduire sur une machine à l'insu de son propriétaire, et de s'y maintenir (que ça soit pour de mauvaises actions ou non). Envoyer des requêtes à une machine, ce n'est pas une intrusion que je sache. Mais il y a certainements d'autres points de loi que j'ignore ....

const int TAILLE_X = 100;
const int TAILLE_Y = 100;
unsigned int i = 0;
int** tab2d = NULL;

tab2d = new int* [TAILLE_X];
if (tab2d==NULL) return -1;
for (i=0; i<TAILLE_X; i++) {
tab2d[i] = new int [TAILLE_Y];
if (tab2d[i]==NULL) {
// delete tous les précédents
return -1;
}
}

Et voilà :)
Et bien suûr on peut faire la même chose en C, il suffit de remplacer l'utilisation de new et delete par malloc() et free();

Zut j'aurai du lire les autres commentaires avant de poster ... :(

Flexible est français (source : le petit larousse illustré 1996).
Je me demande où tu as bien pu trouver que ça ne l'était pas ....

Sinon pour Incroyables vs Indestructibles c'est probablement parce que ça sonne mieux (tu ne trouves pas ?) et que donc ça vend mieux.

Ben quoi, c'est normal non ?
Mais bon, normalement tuxracer c'est juste pour l'introduire aux jeux vidéos : l'année prochaine faut lui acheter une gamecube (ou l'équivalent) et Zelda :)

C'est pas très pratique les tutoriaux en vidéo.
On peut difficilement le suivre pas à pas, à son rythme, alors qu'un tutorial en html permet tout cela.
Seulement un tutorial en vidéo demande moins d'effort à confectionner ...

1- La télévision :
Ce sont ses goûts, même s'ils sont merdiques, en tant que petit copain, tu dois les accepter, à toi de réussir à l'ouvrir à autre chose.

2- L'ordinateur :
C'est le tiens ou le sien ? Parce que si c'est le tiens, elle n'a rien à dire, mais si c'est le sien, pourquoi cherches-tu à lui imposer quelque chose qui visiblement ne lui convient pas ?

3- La voiture :
C'est ta voiture, c'est toi qui as le permis, c'est toi le chef. C'est toi qui choisit la station de radio, qui choisit les itinéraires etc.

4- Le ménage :
A une certaine époque, et même encore dans certains foyers, c'est la femme qui se tape toutes les corvées, et pas seulement le ménage.

5- La musique :
Les goûts, tout ça.

Maintenant j'ai deux remarques à faire :
a) Normalement tu choisis une copine qui a des goûts et une façon de vivre plutôt compatible avec la tienne.

b) Tu privilégies quoi ? Tes principes, tes goûts etc. ou ta vie de couple ? Parce que bon, pour l'ordinateur, le ménage et la musique, je te trouves un peu macho.

Ah et non toutes les filles n'aiment pas que les conneries de TF1 et la télé réalité.

Et puis bon pour le rapport avec le site, je t'aurais bien "inutilé" pour la peine. Ce genre de "problèmes" a plus sa place sur ton blog je pense.

Le bordeau est sensé rappeler le thème par défaut de WindowMaker.

Pour le fond bleu, ok, c'est moche et ringard.

Mais ça n'a rien à voir avec les chasseurs, j'en connais un qui n'a rien des caricatures que je viens de lire dans les commentaires.

Je n'aime pas la chasse parce que :
- On ne peut pas se balader dans les bois sans avoir peur de se prendre une balle perdue
- Quel beau sport : tuer pour le plaisir
- Le gibier a toujours une chance de s'en sortir : il suffit qu'il coure plus vite que la balle
- On maîtrise parfaitement les techniques d'élevage, alors les chasseurs ne font pas ça pour se nourrir, mais uniquement par plaisir
- Quand je vois un bel animal dans son milieu naturel, je lui tires le portrait plutôt qu'une chevrotine

Maintenant, celui qui a tué cet ours n'est pas plus con que le gouvernement qui décrette la chasse de quatre ou cinq loups ... Quand on sait qu'en Italie il y a environ 200 loups et aucun problème avec les paturages, et pour cause : les troupeaux sont en permanence avec un chien, les paturages sont cloturés, les troupeaux dorment à l'abri et non pas en plein air ...

Bref, bref, en France on aime bien diaboliser les animaux dits "dangereux", et on aime bien tuer plus vite que le son.

Quand est-ce qu'on va recommencer à brûler les sorcières ? Il me semble que ça va un peu avec la chasse au loup non ?

En gros, la même chose que le système actuel ... mais en plus compliqué. C'est bien cela ?

Je ne comprends pas bien l'interêt ? C'est de pouvoir faire comme sous l'OS à la fenêtre ?
Non ce n'est pas un troll mais je trouve quand même hyper pratique d'avoir un fichier texte pour la conf de chaque application ou service.
C'est lisible par un être humain, on peut l'éditer soi-même, et quand on désinstalle l'application ou le service en question, il suffit de supprimer le fichier texte correspondant pour qu'il n'en reste aucune trace. Alors qu'avec une base de registre ............

On dirait que pour toi , l'informatique ca se resume à l'embarqué et les jeux ...
Pas du tout, mais il faut en prendre compte pour ne pas prendre de mauvaises habitudes.

On ne parle tout simplement pas de la meme chose.
On dirait effectivement, toi tu parles d'un cas particulier où la performance est tellement critique que la gestion de la mémoire doit être laissée à l'OS ou la VM. Moi je parle du cas général, qui est quand même bien plus fréquent que le tiens.

C'est l'éternel compromis entre la performance et la stabilité. Dans mon expérience, et même dans les cas où la performance était critique (les jeux vidéos tiens), eh bien la stabilité a toujours primé.

non, gc a raison si, en 2004, tu ne peux pas faire confiance au systeme pour desalouer proprement la memoire, alors change d'OS de boite ou de metier !

N'importe quoi ! Vaut mieux lire ça que d'être aveugle ! J'espère que tu n'auras jamais à travailler sur un système embarqué ou un jeu vidéo ... ou une console de jeux vidéos ... Et j'espère que tu ne diras jamais une ânerie pareille à ton patron ...

Moi je dirais plutôt le contraire : il faut partir du principe que l'OS ne désalloue rien à ta place. Comme ça si il désalloue quand même, tant mieux, c'est un parachute, mais s'il ne désalloue rien et que tu fais bien ton boulot, alors tu n'as pas de problème ...
Et ne parlons pas des questions de portabilité ....

C'est pas la peine de rêver, tu n'en viendras jamais à bout ... Ta seule issue est de te sauver par hélicoptère sur une île déserte non contaminée par tous ces zombies ...

(Romero rulez)

Je parlais dans le cas ou tu termines l'execution...

Quand on alloue des objets, on en est responsable. Donc on les désalloue quand on ne s'en sert plus. Et si on commence à compter sur le système pour les désallouer à certains moments et pas à d'autres, alors on en vient vite à ce genre de réflexions : "de toute façon j'ai 256Mo de RAM, je peux la pourrir comme je veux, mon système va tout libérer quand je vais quitter". Et ce qui devait arriver arrive, on prend l'habitude de ne plus désallouer du tout.

C'est sur que c'est tres grave le delete manquant dans un espace d'adressage qui va etre detruit dans la seconde :-)

Oui parce que delete ne fait pas que désallouer la mémoire, en appelant le constructeur il peut faire tout un tas de choses assez indispensables. Tu serais content si ton logger, une fois planté, ne fait pas de fflush(logfile), et que donc tu ne puisses pas retrouver l'origine du plantage car les derniers logs n'apparaîtraient pas dans le fichier ? Après tout, le système désalloue la mémoire c'est bien connu.

Et que dire de ceux qui ont l'habitude de coder comme ça (c'est-à-dire comme des porcs n'ayont pas peur des mots) et qui se retrouvent subitement à travailler sur un autre système, qui, lui, ne désalloue pas la mémoire automatiquement ? Je mantiens donc : ne pas désallouer la mémoire est une mauvaise habitude.

On parle de C++ ici non ? Dans ce cas, si le programmeur fait bien son travail, le travail de déallocation de mémoire se fait dans les destructeurs.
Ensuite, pour les objets alloués dans main(...) deux cas se présentent :

• Si ce sont des pointeurs alloués avec new dans ce cas il FAUT faire un delete sinon le destructeur ne sera pas appelé. Jamais. Même par le système. C'est ce qu'on appelle une fuite mémoire
  


• L'autre cas, c'est celui des objets qui ne sont pas alloués par new (sur le tas, je crois), dans ce cas leur destructeur est appelé dès la sortie du bloc courant (à l'accolade fermante correspondant à l'accolade ouvrante du bloc dans lequel cet objet a été alloué). Mais allouer un gros objet sur le tas est une mauvaise idée ...
  

De toute façon, laisser le système gérer la déallocation mémoire est une mauvaise habitude. Point-barre.

Et si tu faisais tout simplement

catch (char* exception) {
std::cerr << exception << std::endl;
}

?