Pan dans tes dents - Page 6

exemple:

void routinealacon() {
  monObjet machin = new ObjectGenial();
  faisdestrucs();
}
//machin est une variable locale, a partir de l'accolade fermante il sera plus accessible, il pourra être désalloué.

Y'a pas d'opérations quelconques à faire pour que le GC marche, il marche c'est tout, donc c'est automatique, machin sera désalloué

(y'a que dans COM et XPCOM qu'il faut s'emmerder avec les addRef() et les releaseRef(), j'ai toujours pas compris quand il faut appeler ces routines )

-

j'ai pas dit le contraire ^^

quand j'ai écrit le message je pensais surtout a trollage Java /.net en fait. j'aurais du l'expliciter.

Brunni (./150) :
si on retourne un objet on peut l'inscrire dans l'autorelease comme ça il vivra encore un moment jusqu'à ce que l'appelant décide qu'en faire.

bah y'a pas besoin d'autorelease là!

Orion_ (./152) :
Si tu n'a appris que le java tu ne sais pas ce que c'est que de gérer la mémoire, donc tu pourra jamais l'apprendre si tu te cantonne à java.

Vrai et faux... quand tu fais du Java, tu dois aussi t'arracher les cheveux pour paramétrer ton environnement d'exécution, et tu peux être mené à revoir ton code (j'ai le souvenir d'applications Tomcat trop gourmandes, sans possibilité de paramétrer l'env. d'exécution, donc là tu es obligé de faire attention).
Cela dit, ça n'a clairement rien à voir avec ce qu'on peut faire en C ou en ASM, c'est clair.

(J'ai édité ./150 pour le compléter)

squalyl (./153) :

Brunni (./150) :
si on retourne un objet on peut l'inscrire dans l'autorelease comme ça il vivra encore un moment jusqu'à ce que l'appelant décide qu'en faire.

bah y'a pas besoin d'autorelease là!

Oué mais je parlais d'une solution *déterministe* qui ne fait pas intervenir un Garbage Collector, et qui peut donc techniquement donner d'excellents résultats même sur de très faibles processeurs.
Avec l'autorelease pool la seule chose qui est difficile à prévoir, c'est sa taille, qui peut tendre vers l'infini si on ne laisse jamais le temps à la libération d'arriver (c'est pas comme un GC, il ne s'activera pas au milieu).
Bref on est d'accord que ça reste overkill de se soucier de ça sur un desktop, discutable sur un téléphone @ 1 GHz, et en général Java FTW pour accélérer le cycle de développement et éviter les bugs chelou. Maintenant je voulais présenter l'approche que je trouve sympa et que tout le monde ne connaît peut être pas

./154 : Ça n'a aucun rapport. Autant comparer "quel chemin prendre pour utiliser mon carburant au mieux" à "ah tiens, faut pas que j'oublie de faire le plein de mon Hummer avant d'aller faire un tour"

J'avoue, c'est pas faux.

Zerosquare (./156) :

./154 : Ça n'a aucun rapport. Autant comparer "quel chemin prendre pour utiliser mon carburant au mieux" à "ah tiens, faut pas que j'oublie de faire le plein de mon Hummer avant d'aller faire un tour"

Hmmm jolie comparaison

Myth> va faire ton interview de paris hilton au lieu de faire comme si le topic t'intéressait

./158 : Merci

Orion_ (./152) :
Si tu n'a appris que le java tu ne sais pas ce que c'est que de gérer la mémoire, donc tu pourra jamais l'apprendre si tu te cantonne à java.

Et ? si tu te cantonnes à Java, comme tu dis, à quoi cela sert alors d'apprendre à gérer la mémoire ?

Cela veut-il dire qu'un type qui passe de Java à C++ fera une simple traduction mot-à-mot de ses instructions sans chercher à vraiment "apprendre" le langage ? à te lire on dirait qu'une fois appris un langage de haut niveau, on est incapable de penser en bas niveau, et que tout programmeur doit forcément commencer au bas de l'échelle. Pourquoi vouloir les rendre systématiquement multitâches, comme si un "informaticien" devait être un type capable de gérer des réseaux, programmer en 8 langues, avoir des bases de cryptographie, maitriser aussi bien les environnements Windows que Linux...
J'aimerai plutôt savoir, non pas pour ceux qui étudient (seul ou à l'école), mais pour ceux dont l'informatique est la branche d'activité, à quel point il vous a été demandé d'être tellement multi-usage. Celui qui a signé pour être développeur Java a t-il eu son patron venant lui demander "au fait, il faudra que tu en fasses une version obj-c pour l'application iphone" ?

Sincèrement, je pense que c'est moins une façon de programmer que de faire de la programmation (je la mets sous copyright, celle-là, tiens !)...
Ce que je veux dire par-là, c'est que le fait de s'intéresser ou non à la mémoire, à mon sens, est plus lié au niveau d'abstraction qu'on a en développant qu'à la façon même de programmer... typiquement, je trouve normal qu'une personne qui fasse de l'informatique de gestion n'ait pas à se préoccuper de la mémoire, que ça soit en C, en Delphi ou n'importe quoi. Après, une personne qui va développer des outils systèmes ou des services, oui, c'est normal. Mais ce sont des métiers différents, quoi qu'on en dise...

Meowcate (./161) :
Et ? si tu te cantonnes à Java, comme tu dis, à quoi cela sert alors d'apprendre à gérer la mémoire ?

Ça sert à faire des programmes qui ne leakent pas des ressources comme des passoires, par exemple.

Je ne dis pas qu'il faut tout coder en C (ou en assembleur, tiens) pour autant. Mais même si on code dans un langage de haut niveau, il faut avoir un minimum de culture sur comment ce qu'on code va être concrètement exécuté.

Pour moi, prétendre que les langages de haut niveau rendent la programmation plus facile, c'est l'une des plus grandes grandes impostures de l'informatique. Moins laborieuse, certainement ; mais plus facile... si on veut en faire de façon sérieuse, je n'en suis pas sûr du tout. Même avec un langage qui fait le café, si le programmeur choisit une stratégie débile (du genre ajouter des caractères à une chaîne un par un), le programme sera mauvais. Et pour pouvoir comprendre ça, on ne peut pas se retrancher perpétuellement derrière des abstractions.

Les langages évolués sont de prise en main plus simple, donc il y a plus de programmeurs qu'avant ; je suis pas sûr qu'il y en ait davantage de bons.

Zerosquare (./163) :
si le programmeur choisit une stratégie débile (du genre ajouter des caractères à une chaîne un par un), le programme sera mauvais.

Justement, en C c'est une très bonne méthode d'ajouter les caractères un à un (et de fermer avec un \0) Mais pas en Java ^^

En redimensionnant le buffer à chaque fois (ce qui était sous-entendu) ? T'appelle ça une bonne méthode ?

c'est celle de java quand tu fais

String a=""; 
for(int i=0;i<10000000;i++) {
  a= a+"d";
}

Meowcate (./162) :
à quel point il vous a été demandé d'être tellement multi-usage. Celui qui a signé pour être développeur Java a t-il eu son patron venant lui demander "au fait, il faudra que tu en fasses une version obj-c pour l'application iphone" ?

C'est rare de signer pour un langage non? enfin ça doit dépendre.
moi en tout cas, je switche régulièrement entre
-C sous linux, on fait un démon cryptographique
-Java desktop windows, pour mes machinesprogrammes-outils
-JavaCard, pour faire du java sur des cartes à puces (2ko de RAM, 64ko de flash)
-Python pour des outils rapides

Ce qui est rigolo c'est que chaque partie est totalement différente au niveau du domaine, mais chaque morceau apporte des éléments intéressants aux autres bouts.

squalyl (./166) :
-JavaCard, pour faire du java sur des cartes à puces (2ko de RAM, 64ko de flash)

(ça me fait penser au sketch de Coluche qui joue du violon avec des gants de boxe - et le pire est qu'il y arrive )

Zerosquare (./165) :
En redimensionnant le buffer à chaque fois (ce qui était sous-entendu) ? T'appelle ça une bonne méthode ?

Ben non, si je parle de fermer avec un \0

Zerosquare (./167) :

squalyl (./166) :
-JavaCard, pour faire du java sur des cartes à puces (2ko de RAM, 64ko de flash)

(ça me fait penser au sketch de Coluche qui joue du violon avec des gants de boxe - et le pire est qu'il y arrive )

c'est ce que t'as certainement dans ta CB, ça marche tellement bien que c'est vendu dans des milliards de cartes sim aussi. c'est pas un langage rond dans un trou carré.
c'est le seul moyen de faire des programmes cartes portables.

(et j'ai pas trouvé la vidéo pour illustrer )

Meowcate (./161) :

Orion_ (./152) :
Si tu n'a appris que le java tu ne sais pas ce que c'est que de gérer la mémoire, donc tu pourra jamais l'apprendre si tu te cantonne à java.

Et ? si tu te cantonnes à Java, comme tu dis, à quoi cela sert alors d'apprendre à gérer la mémoire ?

GC ça veut pas dire truc magique qui te fais oublier tout tes soucis… Un GC apporte des contraintes sur la mémoire et les performances que tu n'aurais pas si tu t'en passait. Tout ce que ça permet c'est de te garantir à 100% que tu n'auras pas de fuites mémoires (d'objets JAVA, car il n'y a aucune garantie sur la mémoire « non Java »)

Cela veut-il dire qu'un type qui passe de Java à C++ fera une simple traduction mot-à-mot de ses instructions sans chercher à vraiment "apprendre" le langage ?

Je pense fortement que oui.

à te lire on dirait qu'une fois appris un langage de haut niveau, on est incapable de penser en bas niveau

À cœur vaillant rien n'est impossible… Mais bon, c'est pas le cas de tout le monde, loin de là.

et que tout programmeur doit forcément commencer au bas de l'échelle.

En gros tu essayes de nous dire qu'il y a des mecs qui savent construisent des maisons, et qui n'ont pas la moindre idée de pourquoi elles tiennent debout. Mais c'est pas grave car ça, ils pourront l'apprendre plus tard, si ça leur fait plaisir. Et tant pis si la maison s'effondre au premier coup de vent…

Pourquoi vouloir les rendre systématiquement multitâches, comme si un "informaticien" devait être un type capable de gérer des réseaux, programmer en 8 langues, avoir des bases de cryptographie, maitriser aussi bien les environnements Windows que Linux...

Je pense pas que ça soit ça. Mais ça devrait être un prérequis que quiconque (et celà va bien au delà de l'informatique) connaisse le sujet sur le quel il bosse, et comprenne les outils qu'il utilise. C'est la même chose que mathématiques vs. calculatrice. On va pas te demander de faire les calculs, juste de savoir les faire, etc… (Qu'on soit bien d'accord, le calcul c'est le boulot d'une machine hein ^^)

au final j'adore mon boulot parce que c'est exactement ça: impossible d'avancer si on sait pas exactement ce qu'on fait. Il nous arrive de passer des heures (j'exagère^^) sur l'interprétation d'une phrase bizarre dans une spec ,qu'elle vienne de l'ISO ou qu'on l'ait nous même écrite

[pause café] (Merci Flanker !)
[flash]http://www.wat.tv/swf2/497218nIc0K112916562[/flash]

Tout comme le zéro quadratique, je pense que c'est une mauvaise idée de ne faire que du Java...

Les langages de haut niveau sont efficaces pour programmer plus rapidement, mais ils cachent beaucoup de choses (la gestion de la mémoire, par exemple, mais ça peut être la façon de coder les tableaux) dont il faut être conscient si on ne veut pas trop perdre en perf.
Typiquement, si on a oublié que le processeur a un cache, on ne fera pas gaffe à la façon dont on va accéder aux éléments d'un tableau bidimensionnel, alors qu'on aura pas du tout les mêmes perfs si on les lit par colonne ou par ligne.

Utiliser des langages de bas-niveau permet de mieux se rendre compte de ce genre de détails auxquels on finit toujours par être confronté...

Kochise (./132) :
Tout dépend l'implémentation de read() Je suis un jours tombé sur un OS embedded qui en fait lisait la valeur hash incluse dans le FS (ou la générait le cas échéant) ainsi que le mapping VF (virtual file). Du coup si ensuite tu faisais un compare() (ou = et bien il comparait les hash ! Radical...

Attention, si les hashes sont différents, tu peux être sûr que les fichiers sont différents, mais si les hashes sont égaux, il peut y avoir collision, donc tu es quand-même obligé de comparer le contenu dans ce cas! Ras le bol des algorithmes qui présupposent que les collisions de hash n'existent pas, ce sont des bombes logicielles prêtes à exploser à tout moment!

Brunni (./150) :
./145> De plus en plus en fait. Depuis ces dernières années il ne reste quasiment plus que le C(++) et des vieux langages plus mis à jour qui n'ont pas de GC.

Le Fortran est toujours mis à jour (la version la plus récente du standard est Fortran 2003 et ils travaillent sur la prochaine) et n'a pas de GC non plus. (Déjà l'allocation dynamique est considéré comme du tout neuf dans la communauté Fortran, ça n'existe depuis 1990, beaucoup de développeurs en sont toujours à la version précédente de 1977. Donc comme je disais, depuis Fortran 90, il y a l'allocation dynamique, mais seulement avec désallocation explicite, pas de GC.)

squalyl (./151) :
(y'a que dans COM et XPCOM qu'il faut s'emmerder avec les addRef() et les releaseRef(), j'ai toujours pas compris quand il faut appeler ces routines )

Parce que c'est conçu pour le C++ et même le C, qui n'ont pas de comptage de références automatique. En C++, on peut y arriver en ayant 2 classes (une classe privée qui contient le vrai objet et une classe publique qui compte les références, c'est comme ça que fonctionne le partage implicit de Qt), mais ce n'est pas la solution qui a été retenue, probablement parce que ça compliquerait la vie aux développeurs C.

Brunni (./155) :
Bref on est d'accord que ça reste overkill de se soucier de ça sur un desktop

Et bonjour les applications qui consomment toute la mémoire de ma machine, merci! Parce que c'est exactement ce que font les applications en Java! Et dès qu'on veut en faire tourner plusieurs, bonjour le swap! Heureusement que KDE est codé en C++!

squalyl (./169) :
c'est pas un langage rond dans un trou carré.

Non, c'est un langage carré dans un trou rond.

oui enfin si les grands noms de l'industrie son d'accord, c'est tout ce qui compte.

et mes applis java n'ont pas besoin de swap.

Kevin Kofler (./178) :
Heureusement que KDE est codé en C++!

Ca ok, le système ne devrait pas être codé en Java. Par contre pour les applications c'est pas mal sur le principe.