Votre IDE préféré ?

Emmanuel Florac:

Parce que ça t'éclate de rechercher les fuites mémoires et les
pointeurs perdus, toi?

Ol:

Il parait que ça impressionne dans les soirées mondaines.

Ouais, la jet set, les applis en monokini qui bronzent autour des
Autorelease Pools, les cocktail, la musique techno ( pas la java, hein ), et
le ptit personnel qui ramasse les poubelles le lendemain.

Claaaaasse :)

--
Y.

Sam:

Malheureusement, tout ce qui est utile est laid ;

hum. Il est intéressant de lire les bouquins de Norman "the design of
everyday thing" et, sur le sujet de la beauté "Emotional Design: Why We Love
(Or Hate) Everyday Things". Ca serait bien que j'explique pourquoi la
proposition de Sam est fausse, mais je suis flegmard.

Emmanuel:

Pas forcément. Un objet utile n'est pas nécessairement beau; un objet
bien conçu l'est. Exemple : un portable HP est aussi utile q'un portable
Apple, mais il est moche. Une Fiat est aussi utile qu'une Jaguar, mais
elle est moche.

pour les fiat, je m'inscris en faux :-)

convivialement, hein

--
Y.

Laurent BERNE , dans le message <mn.0bcc7d4930031230.5426@laposte.net>,
a écrit :

sinon, on peut quand même envisager le cas suivant :
thread_1 initialise un auto_ptr.
thread_2 est démarré, récupère l'auto_ptr (pendant ce temps là,
thread_1 poursuit son bonhomme de chemin et attends le signal de
thread_2 pour se libérer)
thread_2 termine son traitement. Il envoie le signal à thread_1 qu'il a
terminé.
thread_1 fini son execution, vérifie que le signal est bien arrivé
avant de se terminer. L'auto_ptr est libéré à la fin de la portée.

Ce qui veut quand même dire que thread_1 ne peut pas se terminer tant
que thread_2 tourne. Mettons le cas suivant (que j'ai implémenté
avant-hier en version très simplifiée) :

thread_1 = calcul, qui a besoin d'afficher des graphiques de temps en
temps
thread_2 = gestion de l'affichage, multi-fenêtres, zoom, impression,
etc.

Le thread_1 passe au thread_2 les données graphiques, le thread_2 les
garde jusqu'à ce que la fenêtre soit fermée. Les données graphiques ne
sont pas forcément utiles au thread_1 pour la suite du calcul : il
aimerait pouvoir les supprimer dès que thread_2 en a accusé réception.
Mais pour thread_2, elles sont nécessaires jusqu'à la fermeture de la
fenêtre.

Pour concilier ça avec la visibilité des objets liée à la durée du
contexte qui les a créés, il faut au choix :

- que thread_2 recopie les données graphiques, pas très efficace ;

- que thread_1 attende la fermeture de la fenêtre, ça rend l'utilisation
de threads plutôt inutile.

euh, je commence à perdre le fil de cette partie là..
Je résume donc ma pensée :
1) L'objet dans le conteneur est toujours libéré à la destruction du
conteneur, c'est à dire à la fin de la portée dans laquelle se trouve
le conteneur.
pas de fuite à la sortie du programme.
2) On peut éventuellement (si on a envie quoi) libérer l'objet avant.
3) Si le conteneur est défini hors de la portée où on créer l'objet,
l'objet survit à la portée qui a vu sa création.

J'ai la nette impression que tu es en train de réinventer une version
bancale de la libération de resources par comptage de références. C'est
très bien, le comptage de références, mais il faut être conscient de
deux choses :

- D'une part, ça a une grosse limitation qui est que ça ne peut pas
gérer les structures de données circulaires. Ce n'est pas dramatique,
on peut s'arranger, mais ça n'est pas complètement automatique.

- D'autre part, la vision que tu en as est une bouillie complètement
incompréhensible, et partant, inutilisable, car elle mélange deux
comptages de références complètement différents et incompatibles (un
vrai comptage de références, et le comptage uniquement des références
depuis une clôture).

Plus généralement, le problème de la durée de vie des resources est un
problème compliqué, qui est encore le sujet de recherches très actives.
Tu ne peux pas prétendre l'éliminer d'un revers de main « on alloue tout
sur la pile ». Ce genre d'allocation constitue un cas très efficace
utilisable dans les cas simples, mais n'est pas universel.

On Wed, 1 Sep 2004 16:03:50 +0000 (UTC), Yannick Jestin wrote:

Sam:

Malheureusement, tout ce qui est utile est laid ;

[...] la proposition de Sam est fausse

Je suis tout de même navré que tout le monde s'acharne à m'attribuer
cette citation. On n'apprend plus que Java et C++ à l'école ?

--
Sam.

Nicolas George a émis l'idée suivante :

Laurent BERNE , dans le message <mn.0bcc7d4930031230.5426@laposte.net>,

sinon, on peut quand même envisager le cas suivant :
thread_1 initialise un auto_ptr.
thread_2 est démarré, récupère l'auto_ptr (pendant ce temps là,
thread_1 poursuit son bonhomme de chemin et attends le signal de
thread_2 pour se libérer)
thread_2 termine son traitement. Il envoie le signal à thread_1 qu'il a
terminé.
thread_1 fini son execution, vérifie que le signal est bien arrivé
avant de se terminer. L'auto_ptr est libéré à la fin de la portée.

Ce qui veut quand même dire que thread_1 ne peut pas se terminer tant
que thread_2 tourne. Mettons le cas suivant (que j'ai implémenté
avant-hier en version très simplifiée) :

thread_1 = calcul, qui a besoin d'afficher des graphiques de temps en
temps
thread_2 = gestion de l'affichage, multi-fenêtres, zoom, impression,
etc.

Le thread_1 passe au thread_2 les données graphiques, le thread_2 les
garde jusqu'à ce que la fenêtre soit fermée. Les données graphiques ne
sont pas forcément utiles au thread_1 pour la suite du calcul : il
aimerait pouvoir les supprimer dès que thread_2 en a accusé réception.
Mais pour thread_2, elles sont nécessaires jusqu'à la fermeture de la
fenêtre.

et si le thread 2 est plus rapide et libère la ressource avant que le
thread 1 ait terminé son traitement dessus ?
Il se passe quoi ?
Si tu sais dès le départ que thread_1 aura terminé d'utiliser la
ressource et la passera à thread_2, je vois pas trop l'intérêt de faire
du multi threads.

Pour concilier ça avec la visibilité des objets liée à la durée du
contexte qui les a créés, il faut au choix :

- que thread_2 recopie les données graphiques, pas très efficace ;
constructeur de copie du C++, diablement efficace au contraire. Mais là

n'est pas la question.

- que thread_1 attende la fermeture de la fenêtre, ça rend l'utilisation
de threads plutôt inutile.
Pas forcément. L'intêret du multi thread, c'est qu'un programme fasse

plusieurs actions simultanées, voir plusieurs programmes se
syncrhonisent et travail de concert. Liberer le plus tôt possible un
thread, ca n'a d'interêt que pour liberer de la precieuse RAM et la
réallouer pour autre chose(on est bien d'accord, c'est la bonne méthode
à suivre).


Ce n'est pas moi qui est défini la condition de base "que le thread
allocateur attende gentiment la fin".
Personnellement je ne fais pas comme ça.
Pour ton cas personnel, ca dépend de beaucoup de chose, la lib
utilisée, la méthode de gestions des threads sur ta plateforme, ce que
tu entends par "données graphiques".

euh, je commence à perdre le fil de cette partie là..
Je résume donc ma pensée :
1) L'objet dans le conteneur est toujours libéré à la destruction du
conteneur, c'est à dire à la fin de la portée dans laquelle se trouve
le conteneur.
pas de fuite à la sortie du programme.
2) On peut éventuellement (si on a envie quoi) libérer l'objet avant.
3) Si le conteneur est défini hors de la portée où on créer l'objet,
l'objet survit à la portée qui a vu sa création.

J'ai la nette impression que tu es en train de réinventer une version
bancale de la libération de resources par comptage de références. C'est
très bien, le comptage de références, mais il faut être conscient de
deux choses :

Nan, c'est pas moi qui est inventer ça. Je dirais plutôt Soustroup.
Le comptage par réf, j'en connais les limites (merci COM..)
Y'a une lib toute faite appelée "Standard" qui fait partie de la norme
du langage. Son comportement est défini par cette même norme.
Et il est écrit dans cette norme qu'il y a une tripotée de container
qui s'occupe de cette gestion de mémoire.
Je suis bête et méchant, je fais comme c'est marqué dans les livres et
comme on m'a dit sur les forums.

- D'une part, ça a une grosse limitation qui est que ça ne peut pas
gérer les structures de données circulaires. Ce n'est pas dramatique,
on peut s'arranger, mais ça n'est pas complètement automatique.
ça c'est vrai

- D'autre part, la vision que tu en as est une bouillie complètement
incompréhensible, et partant, inutilisable, car elle mélange deux
comptages de références complètement différents et incompatibles (un
vrai comptage de références, et le comptage uniquement des références
depuis une clôture).
Personnellement, je ne compte rien du tout. J'instancie, j'utilise..

rien de plus.

Plus généralement, le problème de la durée de vie des resources est un
problème compliqué, qui est encore le sujet de recherches très actives.
Tu ne peux pas prétendre l'éliminer d'un revers de main « on alloue tout
sur la pile ». Ce genre d'allocation constitue un cas très efficace
utilisable dans les cas simples, mais n'est pas universel.
Je peux t'assurer que je l'utilise dans des cas "pas simples".

En plus, à ce que j'en sais de Java et C#, les pointeurs y sont
complétement absents.
J'irais pas jusqu'à prétendre que c'est la voie "universelle".
Mais bon, des "acteurs importants" va-t-on dire, s'y sont engagés.
Ne connaissant pas Perl ni python, je ne sais pas comment cela se passe
dans ces langages. Là je suis preneur d'info..

--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser

Laurent BERNE , dans le message <mn.0ca47d498ee842f4.5426@laposte.net>,
a écrit :

et si le thread 2 est plus rapide et libère la ressource avant que le
thread 1 ait terminé son traitement dessus ?
Il se passe quoi ?

Ça dépend. Si c'est moi qui programme, il se passe ce qu'il faut, à
savoir qu'aucun thread n'essaie d'utiliser une zone de mémoire déjà
libérée, et que la mémoire est libérée sitôt qu'elle n'est plus
utilisée.

Si c'est toi qui programme, je n'en sais rien. Je dirais une segfault la
moitié du temps, si on peut juger de tes compétences de programmeur sur
la base de ce que tu dis dans ce thread.

Si tu sais dès le départ que thread_1 aura terminé d'utiliser la
ressource et la passera à thread_2, je vois pas trop l'intérêt de faire
du multi threads.

La situation que j'ai décrite (thread_1 = calcul, thread_2 = affichage)
est pourtant un parfait exemple de cette situation.

constructeur de copie du C++, diablement efficace au contraire.

Diablement efficace peut-être, mais uniquement pour une copie. La copie
en soi est une perte de temps si elle n'est pas nécessaire.

Ce n'est pas moi qui est défini la condition de base "que le thread
allocateur attende gentiment la fin".

C'est la seule manière de procéder si un autre thread utilise une zone
de mémoire allouée dans le contexte de ce thread. C'est justement pour
te mettre le nez dans ce caca que ça a été évoqué.

En plus, à ce que j'en sais de Java et C#, les pointeurs y sont
complétement absents.

C#, je ne connais pas. En Java, des pointeurs, il n'y a que ça, partout.
Mais comme il n'y a que ça, le déréférencement est implicite, et on ne
les voit pas. La libérations des resources pointées se fait par un vrai
garbage collector.

Ne connaissant pas Perl ni python, je ne sais pas comment cela se passe
dans ces langages. Là je suis preneur d'info..

Perl, comme tout langage de très haut niveau, utilise des pointeurs
partout, avec déréférencement implicite. La libération des resources se
fait par comptage de références, et il est nécessaire de couper
explicitement les liens circulaires, ce qui est cependant assez rarement
nécessaire pour le style des programmes habituellements faits en Perl.

D'après Manuel Leclerc:

aucune donnée stockée dans la
portée de cette fonction ne peut survivre (sauf à utiliser
des variables 'static', mais c'est MAL).

Ben, v'la aut' chose.

Primo, c'est assez simple d'encapsuler la notion de thread dans une
classe.

Oui, avec une fonction membre statique.
Zut, c'est mal.

Yannick Jestin <jestin@cena.fr> wrote:

Ouais, la jet set, les applis en monokini qui bronzent autour des
Autorelease Pools

Ouais, les autorelease pools, ça le fait moins pour impressionner en
société, quand même.

Ol.
--
Olivier Gutknecht

Le Wed, 01 Sep 2004 15:39:33 +0000, Yannick Jestin a écrit :

Ben heuuu, http://www.tkzinc.org/index.php/Main/Screenshots , c'est du Tk,
mais avec un remplaçant sympa au canvas.

Mmmh, je vais peut-être me mettre au Tk moi...

--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.

Le Wed, 01 Sep 2004 14:29:48 +0200, Anonyme a écrit :

Le beau n'est pas universel mon ami.

Désolé, il l'est. Je suis rigoureusement dégoûté par le relativisme
qui prévaut actuellement. Mozart est plus beau qu'O-Zone, un tableau de
Dali est plus beau qu'une boîte de patée pour chat, etc.

Le beau n'est pas affaire de conventions sociales. Tu confonds sûrement
avec la mode, ou je ne sais quelle autre connerie vue à la télé.
Ensuite on peut discuter pour classer ceci ou celà... ou sur la
pertinence des exemples choisis...

--
entia non sont multiplicanda praeter necessitatem.
Guillaume d'Ockham.