pasBill pasGates a écrit 16060 commentaires

s/windows 7/Vista

Fait leur manger un poisson avarie, ils comprendront (si ils survivent).

Ben non, le sterilisateur est optionel et est la uniquement pour ceux qui oublient tout le temps de fermer la porte du frigo. Pour le bac a legumes, on sait tous que les legumes c'est bon pour la sante et tres peu de gens veulent une clayette !

Et apres on s'etonne que Linux donne froid dans le dos a Ballmer...

Si tu commandes un yaourt, il te dira qu'il doit d'abord commander 3 litres de lait, 300g de sucre et une barquette de fraise.

Et si tu essaies ensuite de commander un yaourt a la peche, il te dira qu'il y a un conflit entre la barquette de peche et la barquette de fraise

Marrant, parce que de tous les commentaires de cette depeche, il n'y a qu'un commentaire qui contient le mot idiot, et c'est le tien.

Et ca en dit long sur toi et ton apport a ce fil de discussion et ce site en general.

Merci de confirmer que tu n'as rien d'intelligent a dire

Tu vois pas l'utilite de creer un tableau de 64Ko en C sur un systeme qui a 1Mo de RAM et qui peut en addresser 1Mo voire 16 ? Moi oui

Le probleme est quand ce meme code se met a allouer 2Go sur un systeme qui ne peut en allouer que 4 au grand maximum et qui en realite n'en a que 3 ou 2 de disponible en allocation pour un processus, sans compter ce que le systeme utilise et qui reduit et fragmente la quantite disponible.

--> Tu passes d'une allocation qui est 16 ou 256x plus petite que l'espace d'addressage, a une qui est 2x plus petite que l'espace d'addressage, et tu passes d'une tres tres grande chance d'avoir une allocation reussie, a quasiment aucune.

Tu le vois toujours pas le probleme ?

La difference avec les autres langages, c'est qu'avec eux, ta taille d'allocation ne change pas, elle est constante quel que soit le systeme, des surprises du genre tu n'en as pas, si ton code tourne sur un 80x286 avec 16Mo de RAM, tu sais qu'il tournera sur un P4 avec 2Go de RAM, avec le C ce n'est pas le cas.

T'as un truc intelligent a dire au passage ?

Parce qu'un malloc(INT_MAX) sur certains systemes a tout son sens, et sur d'autres absolument aucun, alors qu'un byte[] gros = new byte[java.Integer.MAX_INT] lui a _toujours le meme sens_ ou que ce soit. Et c'est bien ca qui fout la merde avec le C, le meme code se comporte differement d'un systeme a l'autre.

Mais bon, c'est tellement plus simple de sortir des inepties plutot que regarder la verite en face ...

Je te l'ai donnee plus haut la reponse, c'est cette meme reponse qui t'explique pourquoi un malloc(INT_MAX) est tout a fait acceptable sur un CPU tel que le 80286 et que le _meme_ code explose sur un x86 32bit

Tout a fait, le probleme etant de trouver une librairie qui
a) est disponible sur toutes les plateformes que tu veux
b) est utilisable du point de vue de la licence

Avec le framework du langage, c'est simple la question ne se pose pas.

Avec C, vu qu'il n'y a justement pas de framework, ben faut bien chercher et esperer avoir de la chance.

Mais ce n’est pas possible de discuter avec vous, vous remettez en doute sans cesse mes compétences, mais n’hésite pas toi à me donner ton pedigree.

Personnellement, c'est pas que je remettes en cause tes competences, je te connais pas, mais ca fait plus de 15 ans que je fais du C, avec pas mal de multiplateforme justement (j'ai d'ailleurs fait que ca jusqu'a mon arrivee chez MS: un soft tournant sur MIPS, PPC, x86, Sparc avec NetBSD, Linux, IRIX, Windows & Solaris comme OS), alors quand j'entends dire que C c'est un langage multiplateforme, ca herisse les poils, et quand tu me montres plus haut que tu ne comprends pas pourquoi tu peux allouer 1Go sur un systeme avec 1Go de RAM physique, ca me conforte dans l'idee que tu ne maitrise pas forcement tout ce dont tu parles.

Et tu croyais que c'etait quoi d'autre ?

Parce que bon, au final tu peux ecrire une JVM C# ou Java en C, donc en theorie tout ce que tu peux faire en C# / Java tu peux le faire en C, mais faut etre un peu realiste et voir le langage pour ce qu'il est dans un contexte d'utilisation normale.

T'as un soft a ecrire de maniere portable, l'ecrire en Java, C# ou autre Python sera bcp plus facile que l'ecrire en C au niveau portabilite.

Parce qu t'avais un Go d'espace d'addressage libre, et qu'il est alle tape dans la swap pour l'espace utilise qu'il a mappe dans ce 1Go d'espace d'addressage.

C'est pour ca que quand tu veux allouer 2Go sur un systeme 32bit tu commences a avoir de tres tres gros problemes, meme si t'as 4Go de RAM, parce Linux reserve automatiquement 1Go de l'espace d'addressage pour le kernel, ca laisse 3Go, sur lesquels il faut enlever ce qui est utilise par le systeme, et esperer avec ca avoir 2Go continus quelque part.

Resultat, t'as beau avoir 4Go de RAM, les chances d'arriver a allouer 2Go sont plutot faibles, alors qu'avec un 80x86 allouer 64Ko c'est chose facile. Resultat, quand tu passes ton code d'un systeme a l'autre, ca compile joliment et tout, tu lances et 3 minutes plus tard quand il fait l'alloc, boum !

C'est ce genre de choses qui font qu'en pratique, quand tu ecris du code un minimum complexe, tu te retrouves avec des problemes de portage en C.

La difference c'est qu'en Java/C#/autre, t'as rien a faire, et en C tout a faire.

Pour le code, comme je le dis et le répète : c’est portable, rien à faire. Pour du fichier de donnée portable et facile, pas de secret : format texte, printf&co à donf. c’est ce que je fais. Si tu veux du binaires : c’est casse-couille, faut manipuler la mémoire bit-à-bit pour forcer l’endianess&co, c’est portable, juste casse-couille, je n’ai personnellement jamais fait donc je ne saurais te pondre le code là comme ça en 10 minutes, mais c’est possible : c’est ce que fait très certainement la JVM, y’a pas de miracle !

C'est bien, tu commences a comprendre que c'est casse-couille la ou d'autres langages font cela de maniere transparente.
Tu commences a comprendre pourquoi on considere C comme pas trop portable en comparaison de ces langages.

Ensuite, tu te rendras compte que dans enormement de cas un format texte n'est pas realiste, et tu comprendras que dans enormement de cas C est casse-couille.

Moi je regardes la realite, sur les processeurs x86 16bits, allouer 64Ko ca se faisait tres regulierement et passait sans probleme car les machines avaient frequemment jusqu'a 16Mo de RAM (80286) et quasi toujours au moins 512Ko.

Allouer 2Go sur un processeur x86 32bits, dans 95% des cas l'allocation ne fonctionne pas car le systeme n'a pas 2Go dispo lineairement dans son espace d'addressage

Tu crois ? Tu penses quoi du 8086 qui etait un processeur 16bit avec 20bit d'addressage ?

Sur un systeme avec entiers 16bits ca a son sens, tu veux allouer un tableau de la taille maximale (une entree pour chaque index possible), ca prend pas enormement de place.

Le probleme etant que des que tu passes sur un autre systeme, ca pete, parce que la taille du type de donnee a change.

Un truc pareil, avec des dizaine d'autres langages cela n'arriverais pas.

Jolie facon d'evader la conversation...

Non je parles de realite.

Amuses toi avec un truc du genre :

int* MyArray=malloc(INT_MAX); --> alloue 32Ko sur une machine avec entiers de 16bit, ce qui est tout a fait acceptable.

Maintenant va passer ca sur une machine avec entiers en 32bit et prend toi l'allocation de 2Go dans la tronche, ca va etre drole...

Quand a Java, si j'en crois http://download.oracle.com/javase/tutorial/java/nutsandbolts(...) c'est tres clair, un int est 32bit, quel que soit l'OS du dessous (normal vu que la JVM donne une plateforme abstraite identique partout).

Ah mais si c'etait si simple hein ?

Un entier de 16bit, ca fait 65536 valeurs, un entier de 32bits plus de 4 milliards.

Alors, ton soft il passe de l'un a l'autre, tu crois que c'est sans effet de bord ?

Genre ton soft qui faisait des allocations de 64Ko, maintenant risque d'en faire de 4Go, ou autre difference, etc...

Faut se reveiller un peu, porter du code non-trivial en C, c'est pas tout simple.

Quand a la #define INT_MAX codee en dur, tu appelles ca de l'incompetence, moi j'appelles ca vivre dans la vraie vie ou 95% des etudiants sortis d'universite ne savent pas que INT_MAX existe.

Non, le juge les enverra chier, vu que c'est contractuel.

http://www.slingshotsoftware.com/news/slingshot-adds-support(...)
http://www.medsphere.com/solutions/system-architecture
http://www.sourcegear.com/vault/index.html
etc...

De rien

Grande nouvelle, t'as pas besoin du 5eme argument de GetDevicePropertyW , t'utilises reg.exe query <ce que tu veux> et tu trouves

Ensuites quand tu veux changer une valeur, t'utilises reg.exe set <ce que tu veux>

etc...

Si tu veux envoyer ta config, t'as reg.exe export

Tu peux comparer avec reg.exe compare

etc...

Et bien evidemment tu peux scripter ca dans tous les sens, et c'est de base dans l'OS depuis des annees.