Ça fait mal de lire des choses aussi… hmmm… inexactes.
Déjà, faut-il rappeler les compilateurs C produisent de l'assembleur avant de compiler en langage machine ? Et que donc, un OS écrit uniquement en assembleur est envisageable ? http://www.menuetos.net/
Ce n'est pas pour râler sur l'absence apparent de liens. Mais tout simplement, en voyant le titre, j'ai cru que j'allais consulter un documentaire intéressant sur la démocratie au sein du projet Debian.
Oh oui, avec un shell qui change de comportement selon qu'on se connecte à un serveur de config, un mongos, un mongod, un répliqué, etc. Et bien sûr, pas de gestion des erreurs, avec un usage de dialog très somaire. Très abordable, je confirme.
Mais bon, l'outil a peut-être été amélioré depuis la dernière fois où je l'ai utilisé.
L'article est tellement flou que je me demande comment elle peut transmettre quoi que ce soit en formation. Mais il faudra m'expliquer où elle a vu qu'on appelait spork un fork antagoniste.
Je crois que l'article sous lequel nous trollons, concerne C++.
Cependant, je ne suis pas certain que ce problème d'exception levée dans un destructeur soit spécifique à C++. C'est une patate chaude que la norme avait balancé dans le domaine du comportement indéfini, mais il faut bien avouer qu'il n'est pas évident à apporter une réponse claire et nette à cette question : « quel est l'état d'un objet en court de destruction qui voit se lever une exception durant sa destruction ? » On aura un objet pas complètement détruit qui risque de pourrir l'état du programme : que doit-on faire, à part paniquer et tuer le programme ?
Un smart pointer est un objet qui encapsule un pointeur, il y a donc bien une allocation de l'objet qui encapsule. Tu peux mettre ce que tu veux comme pointeur dedans, qu'il soit valide ou invalide ne change rien au fais qu'il y a bien allocation d'une coquille pour stocker le pointeur et son compteur de références.
Tout d'abord, je n'avais effectivement pas compris que tu parlais du détail d'implémentation (la coquille) pour argumenter que le smart pointer faisait une allocation à l'instantiation du shared_ptr. C'est un détail d'implémentation qu'il fait une allocation mémoire. On pourra imaginer un smart_pointer qui utilisera une zone statique, et dans ce cas là tu n'auras pas d'allocation comme tu l'entends.
En fait, ce que je comprenais de tes explications, c'est que je pensais que tu croyais que le smart pointer alloue un objet par défaut. Ce qui serait une erreur de conception, puisque tout les objets n'ont pas un constructeur par défaut explicite.
Lever une exception dans un destructeur mène a un comportement indéfini (ton programme se retrouvera dans un état impossible à prédire).
L'appel à std::fstream::close peut lever une exception en cas d'échec http://www.cplusplus.com/reference/iostream/fstream/close/
Donc, laisser l'objet gérer la fermeture du fichier peut mener à un comportement indéfini.
Dans le cas de std::shared_ptr<>::release, c'est moins problématique. En effet, un destructeur devrait être nothrow. Maintenant, imagine le combo :
Si la fermeture du fichier lève une exception pour une raison quelconque, quel sera l'état du programme pour peut qu'on attrape les exceptions quelque part ?
L'intérêt d'un RIAA, c'est que la ressource ne va pas fuiter. Par contre, ça ne garanti pas que le programme va correctement fonctionner si le destructeur n'est pas exception-free.
J'aimerais bien comprendre pourquoi je suis moinsé alors que je corrige une erreur de débutant.
Ben non, le constructeur de std::shared_ptr n'alloue pas d'objet. Le constructeur par défault créé un smart pointer invalide.
#include <memory>intmain(){std::shared_ptr<int>pipi;*pipi=42;// Comportement indéfini car *pipi pointe sur rien// pas d'exception parce que ça ne correspond pas à la sémantique des pointeurs}
Non, le but n'est pas d'automatiser la destruction : c'est d'éviter la fuite de ressources.
Par exemple, si tu as un objet RAII qui, lors de sa destruction, risque d'émettre une exception, le comportement sera indéfini car l'exception sera levée dans le destructeur de l'objet RAII.
Donc il faut toujours explicitement libérer la ressource pour être certain d'avoir un comportement défini.
Dans l'absolu, il ne faudrait jamais laisser un objet RIIA libérer tout seul ces ressources : il vaut mieux explicitement la fonction de libération. En tout cas, en C++ c'est obligatoire si la libération de la ressource est susceptible de lever une exception (comportement indéfinis lors de la levée d'une exception dans un destructeur).
Le GC s'occupe de gérer de la mémoire, allocation et désallocation, comme je l'ai noté. La notion fondamentale est qu'ici on compare un outil de la gestion de la vie d'objets en mémoire (un GC), avec un gestionnaire de libération de ressource (quelconque). Oui, on peut utiliser std::shared_ptr pour autre chose qu'un pointeur sur le tas, il suffit de spécialiser le libérateur.
Le constructeur du smart pointer ne peut pas être vu comme l'allocateur de ressource, pour la simple et bonne raison qu'il n'alloue rien du tout. Ce n'est pas sa responsabilité.
#include <memory>std::shared_ptr<int>pipi;// N'alloue pas un int
Ce que je ne comprends pas, c'est que tu te ramène avec des histoire de GC alors qu'on parle d'un objet RIAA. Pour ainsi dire, ça n'a pas grand chose à voir.
Un GC gère l'allocation et la désallocation coordonnée d'objets.
Un RIAA ne gère que la libération d'une ressource.
Est-ce que le standard garanti que std::shared_ptr est thread-proof ?
Est-ce que si std::shared_ptr est conçu pour fonctionner dans un contexte multi-thread, le recours à un mutex est systématique même quand aucun mécanisme de multi-threading n'est activé ?
Il faudrait se plonger dans le draft. Je t'en prie, passe devant.
[^] # Re: Génie
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 1.
C'est pour ça qu'il a finalement abandonné son bébé ? :D
[^] # Re: Et pas un mot dans la presse
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 2.
Ça fait mal de lire des choses aussi… hmmm… inexactes.
Déjà, faut-il rappeler les compilateurs C produisent de l'assembleur avant de compiler en langage machine ? Et que donc, un OS écrit uniquement en assembleur est envisageable ?
http://www.menuetos.net/
Il y a plein d'OS écrits en des langages aussi incongrus qu'étonnant dans leur usage.
Java: http://www.operating-system.org/betriebssystem/_english/bs-javaos.htm
C++: BeOS/HaikuOS
Et il me semble avoir déjà croisé le chemin d'OS écrits en Lisp, en Scheme, en D, etc. Bref, tu devrais un peu chercher avant de raconter des bêtises.
À l'instar de l'andouille, le troll requiert de la qualité, il doit un peu sentir la merde, mais pas trop.
[^] # Re: on attend les trolls
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Modelio, un AGL UML propriétaire passe en GPL. Évalué à 3.
Rien n'est comparable à Windev, voyons.
[^] # Re: lzPack ?
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Communautés open source, stratégies et écueils. Évalué à 2.
Mais encore ? Il installe les chaudières, c'est ça ? :D
[^] # Re: pms
Posté par LupusMic (site web personnel, Mastodon) . En réponse au sondage Quel est votre lecteur audio ?. Évalué à 1.
On a bien les libcaca et libpipi :D
[^] # Re: Respect...
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 2.
Oui, du coup on fait peur à ceux qui voudraient malgré tout dire du mal.
# Le lien avec Linux
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Debtocracy. Évalué à 10.
Ce n'est pas pour râler sur l'absence apparent de liens. Mais tout simplement, en voyant le titre, j'ai cru que j'allais consulter un documentaire intéressant sur la démocratie au sein du projet Debian.
Oui je sais, je vais me cacher.
# Step by step
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche GeneticInvasion : des algorithmes évolutionnaires pour un meilleur jeu. Évalué à 1.
Personne ne l'avait faite, je me dévoue pour la gloire de ma WiiBoard qui prend la poussière.
[^] # Re: Dépêche intéressante, mais imprécise
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Sortie de MongoDB 2.0 RC. Évalué à 2.
Oh oui, avec un shell qui change de comportement selon qu'on se connecte à un serveur de config, un mongos, un mongod, un répliqué, etc. Et bien sûr, pas de gestion des erreurs, avec un usage de dialog très somaire. Très abordable, je confirme.
Mais bon, l'outil a peut-être été amélioré depuis la dernière fois où je l'ai utilisé.
[^] # Re: Ce que je cherchais
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Modoboa 0.8.6. Évalué à 2.
Tant qu'on est pas dans l'exotique (besoins de performances), un ORM est effectivement intéressant (oui, il est velu celui-là).
[^] # Re: Fork ?
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Revue de presse de l'April pour la semaine 34 de l'année 2011. Évalué à 1.
L'article est tellement flou que je me demande comment elle peut transmettre quoi que ce soit en formation. Mais il faudra m'expliquer où elle a vu qu'on appelait spork un fork antagoniste.
# Allergie de jQuery à l'augmentation des types.
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche 3 bibliothèques javascript à découvrir : D3, Sugar et Batman. Évalué à 2.
On sent que eux aussi ont dégusté ce que les gars de jQuery appellent une fonctionnalité http://sugarjs.com/native
[^] # Re: Une session quotidienne
Posté par LupusMic (site web personnel, Mastodon) . En réponse au sondage Après le démarrage de mon environnement de bureau favori, je lance.... Évalué à 0.
C'est pour ça qu'il lance le gestionnaire de tâches après.
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 1.
Je t'invite à consulter l'entrée 8 de ce bouquin : http://www.amazon.com/Effective-Specific-Improve-Programs-Designs/dp/0321334876
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 2.
Je crois que l'article sous lequel nous trollons, concerne C++.
Cependant, je ne suis pas certain que ce problème d'exception levée dans un destructeur soit spécifique à C++. C'est une patate chaude que la norme avait balancé dans le domaine du comportement indéfini, mais il faut bien avouer qu'il n'est pas évident à apporter une réponse claire et nette à cette question : « quel est l'état d'un objet en court de destruction qui voit se lever une exception durant sa destruction ? » On aura un objet pas complètement détruit qui risque de pourrir l'état du programme : que doit-on faire, à part paniquer et tuer le programme ?
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 1.
Tout d'abord, je n'avais effectivement pas compris que tu parlais du détail d'implémentation (la coquille) pour argumenter que le smart pointer faisait une allocation à l'instantiation du shared_ptr. C'est un détail d'implémentation qu'il fait une allocation mémoire. On pourra imaginer un smart_pointer qui utilisera une zone statique, et dans ce cas là tu n'auras pas d'allocation comme tu l'entends.
En fait, ce que je comprenais de tes explications, c'est que je pensais que tu croyais que le smart pointer alloue un objet par défaut. Ce qui serait une erreur de conception, puisque tout les objets n'ont pas un constructeur par défaut explicite.
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 4.
Wikipedia n'est pas une source.
Je crois que tu ne comprends pas le problème ici.
Lever une exception dans un destructeur mène a un comportement indéfini (ton programme se retrouvera dans un état impossible à prédire).
L'appel à std::fstream::close peut lever une exception en cas d'échec http://www.cplusplus.com/reference/iostream/fstream/close/
Donc, laisser l'objet gérer la fermeture du fichier peut mener à un comportement indéfini.
Dans le cas de std::shared_ptr<>::release, c'est moins problématique. En effet, un destructeur devrait être nothrow. Maintenant, imagine le combo :
Si la fermeture du fichier lève une exception pour une raison quelconque, quel sera l'état du programme pour peut qu'on attrape les exceptions quelque part ?
L'intérêt d'un RIAA, c'est que la ressource ne va pas fuiter. Par contre, ça ne garanti pas que le programme va correctement fonctionner si le destructeur n'est pas exception-free.
J'aimerais bien comprendre pourquoi je suis moinsé alors que je corrige une erreur de débutant.
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 1.
Ben non, le constructeur de std::shared_ptr n'alloue pas d'objet. Le constructeur par défault créé un smart pointer invalide.
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 2.
Non, le but n'est pas d'automatiser la destruction : c'est d'éviter la fuite de ressources.
Par exemple, si tu as un objet RAII qui, lors de sa destruction, risque d'émettre une exception, le comportement sera indéfini car l'exception sera levée dans le destructeur de l'objet RAII.
Donc il faut toujours explicitement libérer la ressource pour être certain d'avoir un comportement défini.
[^] # Re:Débile
Posté par LupusMic (site web personnel, Mastodon) . En réponse au sondage L'écran de mon ordinateur est orienté. Évalué à 4.
Ben ouais, il l'a dit que c'était pour afficher Emacs.
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à -1.
Dans l'absolu, il ne faudrait jamais laisser un objet RIIA libérer tout seul ces ressources : il vaut mieux explicitement la fonction de libération. En tout cas, en C++ c'est obligatoire si la libération de la ressource est susceptible de lever une exception (comportement indéfinis lors de la levée d'une exception dans un destructeur).
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 1.
Le GC s'occupe de gérer de la mémoire, allocation et désallocation, comme je l'ai noté. La notion fondamentale est qu'ici on compare un outil de la gestion de la vie d'objets en mémoire (un GC), avec un gestionnaire de libération de ressource (quelconque). Oui, on peut utiliser std::shared_ptr pour autre chose qu'un pointeur sur le tas, il suffit de spécialiser le libérateur.
Le constructeur du smart pointer ne peut pas être vu comme l'allocateur de ressource, pour la simple et bonne raison qu'il n'alloue rien du tout. Ce n'est pas sa responsabilité.
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à -4.
Ce que je ne comprends pas, c'est que tu te ramène avec des histoire de GC alors qu'on parle d'un objet RIAA. Pour ainsi dire, ça n'a pas grand chose à voir.
Un GC gère l'allocation et la désallocation coordonnée d'objets.
Un RIAA ne gère que la libération d'une ressource.
[^] # Re: templates variadiques
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à -1.
Est-ce que le standard garanti que std::shared_ptr est thread-proof ?
Est-ce que si std::shared_ptr est conçu pour fonctionner dans un contexte multi-thread, le recours à un mutex est systématique même quand aucun mécanisme de multi-threading n'est activé ?
Il faudrait se plonger dans le draft. Je t'en prie, passe devant.
[^] # Re: La blague du jour
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche PyconFR 2011: Inscrivez-vous !. Évalué à 4.
« Mon premier est un serpent danchereux.
- Mon second est sur un toit
- Mon tout est au fond d'un garache alsacien.
- Un piton t'huile »
Oui, c'est encore plus lourd.
http://www.youtube.com/watch?v=Xzcmhty7D1U