Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage Perl eval + return = fin du monde

eval + return = fin du monde

26 réponses
Avatar
luc2
#!/usr/bin/perl

use strict;

# bonjour, je pensais empecher la fin du monde en utilisant "return",
# mais j'ai echoue. je comprends a peu pres le pourquoi du comment,
# mais j'ai pas apprecie le piege...

sub fin_du_monde
{
eval
{
return "je quitte la fonction pour eviter la fin du monde\n";
};

return "destruction de l'univers\n";
}

print fin_du_monde;
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
espie
In article <4e71fb9e$0$16463$,
luc2 wrote:
Le 14-09-2011, Paul Gaborit a écrit :
Il existe de vrais pièges en Perl (commme dans tous les autres langages)
qui, eux, sont mal ou pas documentés du tout. Par exemple, le piège des
fuites mémoires liées aux références circulaires n'est qu'évoqué dans
perlref avec un renvoi vers perlobj qui l'explique un peu mieux mais ne
fournit pas de solution. Ça, c'est un vrai piège du langage difficile à
comprendre et difficile à résoudre.



ce n'est pas parce qu'il existe des pieges plus vicieux que celui-ci n'en est
pas un.



ce n'est pas parce que tu insistes que c'est un vrai piege que c'en est un.
Avatar
Paul Gaborit
À (at) Thu, 15 Sep 2011 19:57:08 +0200,
Alain Ketterlin écrivait (wrote):

Erwan David writes:

Paul Gaborit écrivait :



Un exemple tout simple :

{
my $pere = {};
$pere->{fils} = {pere => $pere};
}

Normalement, cette structure de données devraient étre détruite à la fin
du bloc... Mais elle ne l'est pas à cause des références circulai res (le
père référence son fils qui référence son père...). C'est d onc une fuite
mémoire.



tu veux dire que le GC de perl est un simple compteur de références ?
Ça faut quand même des années qu'on sait faire mieux...



Je partage ta stupéfaction, et en allant lire les documents auquel Paul
faisait référence, j'ai bien peur que ce soit le cas...



Les créateurs de Lisp disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
programmeur. C'est le système qui doit s'en occuper lui-même. »

Les créateurs du C disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
système. C'est le programmeur qui doit s'en occuper lui-même. »

Perl utilise effectivement un système de gestion par compteur de
références. C'est un choix parfaitement pragmatique.

Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.

Pour les cas plus complexes, l'utilisation des références faibles ou
d'une destruction programmée suffit.

Seul les cas où il y a des nombreux cycles créés et détruits sans m oyen
de prédiction simple de le faiblesse ou non des références peut poser de
réels problèmes et nécessiteraient effectivement un ramasse-miettes p lus
« puissants ». Mais la mise en ½uvre d'un tel ramasse-miettes est
nécessairement coûteuse et ne vaut pas le coup d'être payé s'il n'e st
pas nécessaire.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Avatar
Alain Ketterlin
Paul Gaborit writes:

À (at) Thu, 15 Sep 2011 19:57:08 +0200,
Alain Ketterlin écrivait (wrote):

tu veux dire que le GC de perl est un simple compteur de réfé rences ?
Ça faut quand même des années qu'on sait faire mieux...



Je partage ta stupéfaction, et en allant lire les documents auquel Paul
faisait référence, j'ai bien peur que ce soit le cas...



Les créateurs de Lisp disaient : « La gestion de la mà ©moire est une
chose tellement importante qu'on ne peut pas la laiser au
programmeur. C'est le système qui doit s'en occuper lui-mê me. »

Les créateurs du C disaient : « La gestion de la mémo ire est une
chose tellement importante qu'on ne peut pas la laiser au
système. C'est le programmeur qui doit s'en occuper lui-mê me. »



Tout à fait d'accord, avec les deux. Mais j'aurais du mal à dà ©fendre :
« La gestion de la mémoire est une chose tellement important e que quand
c'est facile on la laisse au système et quand c'est plus compliquà © on
demande l'aide du programmeur. »

[...]
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.



J'aurais dit exactement le contraire, mais je n'ai pas l'intention de
verser dans le débat religieux.

-- Alain.
Avatar
Paul Gaborit
À (at) Fri, 16 Sep 2011 00:09:58 +0200,
Alain Ketterlin écrivait (wrote):

Paul Gaborit writes:


Les créateurs de Lisp disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
programmeur. C'est le système qui doit s'en occuper lui-même. »

Les créateurs du C disaient : « La gestion de la mémoire est une
chose tellement importante qu'on ne peut pas la laiser au
système. C'est le programmeur qui doit s'en occuper lui-même. »



Tout à fait d'accord, avec les deux. Mais j'aurais du mal à défendre :
« La gestion de la mémoire est une chose tellement importante que quand
c'est facile on la laisse au système et quand c'est plus compliqué on
demande l'aide du programmeur. »



C'est bien la bonne formulation. ;-)

[...]
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.



J'aurais dit exactement le contraire,



C'est quoi « exactement le contraire » ?

Que la plupart des programmes nécessitent des références cycliques ? Que
ce n'est pas le meilleur choix lorsqu'il n'y a pas de références
cycliques ? Autre chose ?

mais je n'ai pas l'intention de verser dans le débat religieux.



Personnellement, ce n'est pas une religion mais juste mon expérience. Il
n'existe pas de ramasse-miettes meilleur que les autres pour toutes les
situations. De tous les langages que j'ai pratiqués (dont C, C++, Java,
Lisp, Prolog, Fortran) pour manipuler des structures de données
complexes, Perl est celui qui, jusqu'à maintenant, m'a posé le moins de
soucis avec la gestion de la mémoire. Mais mon appréciation n'est pas
définitive.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Avatar
Denis Dordoigne
Bonjour,

Ça ne prête à confusion que pour ceux qui ont des idées préconçues sur
le fonctionnement de 'return' et de 'eval'.



une grosse majorite quoi...



A priori la majorité de ceux qui ont appris à utiliser eval l'ont fait en lisant
la doc, et n'ont donc pas d'idées préconçues... D'ailleurs j'ai une question :
comment as-tui découvert eval, et d'après toi à qui ça sert ?


--
Denis Dordoigne
Membre de l'April - promouvoir et défendre le logiciel libre - april.org
Rejoignez maintenant plus de 5 000 personnes, associations,
entreprises et collectivités qui soutiennent notre action
Avatar
Alain Ketterlin
Paul Gaborit writes:

[...]
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.



J'aurais dit exactement le contraire,



C'est quoi « exactement le contraire » ?



Selon moi, la plupart des programmes utilisent des références cyc liques.
Seuls les plus simples ont un graphe de données parfaitement
arborescent.

[...] Il n'existe pas de ramasse-miettes meilleur que les autres pour
toutes les situations. [...]



Ce n'est pas la question. La question c'est : y a-t-il un ramasse-miette
ou pas ? Pour Perl, la réponse est : "oui mais non".

(Et si la question est de savoir comment implémenter un ramasse-miette,
cela fait longtemps que les solutions mixtes existent : OCaml utilise
des stratégies différentes pour des générations diffà ©rents, Python fait
du comptage de référence et une collection des données cycli ques
au besoin, Java te permet même de changer de gc selon l'application,
etc.)

-- Alain.
Avatar
Paul Gaborit
À (at) Fri, 16 Sep 2011 14:54:22 +0200,
Alain Ketterlin écrivait (wrote):

Paul Gaborit writes:

[...]
Pour la plupart des programmes, c'est le meilleur choix puisqu'ils
n'utilisent pas de références cycliques.



J'aurais dit exactement le contraire,



C'est quoi « exactement le contraire » ?



Selon moi, la plupart des programmes utilisent des références cycliques.
Seuls les plus simples ont un graphe de données parfaitement
arborescent.



Heu... Sans cycle ne veut pas dire nécessairement arborescent ! Je ne
suis pas certain que les cycles soient si courants que cela. D'autant
moins, si on ne parle que des cycles où le développeur ne peut pas
facilement indiquer quelles sont les références faibles.


[...] Il n'existe pas de ramasse-miettes meilleur que les autres pour
toutes les situations. [...]



Ce n'est pas la question. La question c'est : y a-t-il un ramasse-miette
ou pas ? Pour Perl, la réponse est : "oui mais non".

(Et si la question est de savoir comment implémenter un ramasse-miette,
cela fait longtemps que les solutions mixtes existent : OCaml utilise
des stratégies différentes pour des générations différents, Python fait
du comptage de référence et une collection des données cycliques
au besoin, Java te permet même de changer de gc selon l'application,
etc.)



Oui, je sais tout ça... Mais toutes ces solutions ont un coût ! Pourquoi
le payer lorsque ce n'est pas nécessaire ?

En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).

C'est sur ce principe que fonctionne Perl 6 (en fait la machine
virtuelle Parot).

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Avatar
Erwan David
Paul Gaborit écrivait :


En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).



Un simple mark & sweep à 3 couleurs c'est pas couteux et ça marche (j'en
ai implémenté un en embarqué avec une mémoire de l'ordre de 64 ko).
Après on peut faire plus fin en le faisant génératif, temps réel ou
concurrent...


--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Avatar
Paul Gaborit
À (at) Fri, 16 Sep 2011 19:23:24 +0200,
Erwan David écrivait (wrote):

Paul Gaborit écrivait :


En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).



Un simple mark & sweep à 3 couleurs c'est pas couteux et ça marche (j'en
ai implémenté un en embarqué avec une mémoire de l'ordre de 64 ko).
Après on peut faire plus fin en le faisant génératif, temps réel ou
concurrent...



Un "mark & sweep" ainsi que son amélioration à "3 couleurs" introduisent
des phases de ramassage des miettes qui arrêtent momentanément le
programme (et qui forment le coût supplémentaire que j'évoquais). De
plus, certains objets sont détruits avec retard (alors qu'ils sont hors
de portée depuis longtemps). L'intérêt est évidemment qu'on n'a pas à se
soucier des cycles.

L'intérêt du simple comptage de références (combiné avec des références
faibles ou un cassage manuel des cycles) est de garantir une destruction
des objets au moment où ils deviennent hors de portée et des phases de
destruction dont le coût est exactement lié au nombre d'objets détruits
(le comportement est déterministe). L'inconvénient est évidemment de
créer des fuites mémoire si on oublie de gérer les cycles d'une manière
ou d'une autre.

Le choix pragmatique en Perl 5 a été la deuxième solution pour des
raisons de performances. Il est évidemment discutable (c'est d'ailleurs
ce qu'on fait ;-)). Mais il n'est pas condamnable en tant que tel.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Avatar
espie
In article ,
Erwan David wrote:
Paul Gaborit écrivait :


En fait, ce qui manque à Perl 5, ce sont des ramasses-miettes plus
puissants (mais plus coûteux) qu'on pourrait activer au besoin (dans les
cas où les compteurs de référence couplés aux références faibles ne
suffisent pas ou dans les cas où le developpeur ne veut vraiment pas se
soucier de la gestion mémoire).



Un simple mark & sweep à 3 couleurs c'est pas couteux et ça marche (j'en
ai implémenté un en embarqué avec une mémoire de l'ordre de 64 ko).
Après on peut faire plus fin en le faisant génératif, temps réel ou
concurrent...



Erwan, comme souvent... Si c'est si facile a faire que ca, et si tu l'as
deja fait, qu'est-ce que tu attends pour nous filer un patch pour perl5.

Ah oui, j'oubliais, t'es pas paye pour ca.
1 2 3