Reprise du message précédent :

multisampling ? ( https://www.opengl.org/registry/doc [...] 061201.pdf 3.2.1)

on m'a envoyé en déplacement sur paris pour une mission pompier. On m'a dit, tu verras, c'est mieux, c'est trop beau  paris en plus.
 
de la fenêtre de mon bureau, je vois l'yvette, la foret derrière, des bernaches qui dorment sur l'herbe.
 
et maintenant :  
 

Putain 17k emails envoyés ce mois-ci

Nouveau record

edit : ça reste pas grand chose, mais un record est un record

Nunux est prêt pour le mobile ?

https://jolla.com
https://www.tizen.org

toi aussi t'as un jolla ?

et un peu android, quand même

Question backup de données : y a t'il des outils tout prêt pour vérifier que tout se passe bien ?

Tu fais ton backup puis tu redéployes quelque part et vérifie que la version déployée correspond au truc sauvegardé histoire de valider les données et la stratégie de récupération.

Edit : par données j'entends bdd et documents, pas dossiers pleins de porn.

Les outils de backups un peu évolués propose une relecture des données backupées pour voir s'il n'y a pas eu d'erreur.
Ton truc semble impliquer deux copies, je ne vois pas trop l'intérêt.

On est proche des 500 mails par jour, tu trouves le temps de coder ?

 
Mails d'inscription et de rappels XO, et mail lors d'une release Mes mails perso, j'sais pas du tout à combien je suis.
 
De toute façon, je code quasi pas... Sur XO je fais des issues, relecture de PR, gestion du projet, sans oublier la côté « idée » et stratégie/orientation du projet.

http://www.allgov.com/news/unusual [...] ews=852822
turtles all the way down. En plus de perdre un sous-marin pour une débilité, ils vont le transporter du Maine à Washington ????

 
« Et toi, t'es au taule pour quoi ? »
- « J'ai foutu l'feu à un putain de sous-marin nucléaire. 2 fois. »
 
     

Moi je retiens ça surtout :
 

Question C++ :

• en C++ on fait du RAII pour bien tout libérer les ressources dans le dtor, car on est des gens propres on gère pas les free/close/delete à la main
• en C++ un dtor ne doit jamais lancer d'exception sous peine de bien tout péter la stack

Du coup comment on récupère une erreur d'un close() quelconque ayant lieu dans un dtor ?

C'est marrant moi je me suis toujours demandé la même chose, en particulier comment un close() pourrait échouer. Du coup je bouffe toujours les exceptions des close() et j'envisage pas que la ressource puisse ne pas être libérée après que close() a échoué, j'ai pas d'action alternative.

Alors les hommes, on a n'a pas la patate?

c'est très bon la série sur arte qui passe maintenant.

En fait la seule façon de faire que je vois serait d'appeler soi-même la méthode qui libère les ressources et qui traite les cas d'erreurs proprement, et d'avoir dans le dtor un appel vers une variante de cette méthode qui fait ce qu'elle peut mais noie les erreurs.
Du coup le RAII devient moins attrayant...

Pourquoi ne pas passer par un gestionnaire pour les ressources qui ont un close au résultat incertain?

Dans ton dtor tu lui indique juste que tu ne l'utilises plus et c'est au gestionnaire de se démerder de son côté.

On écrit des close qui n'échouent jamais. Concrétement, ça veut juste dire qu'on traite la cause de l'exception immédiatement quand on est dans un destructeur.

Comme toujours en C++, la difficulté est pour celui qui écrit la bibliothèque. Le RAII c'est intéressant pour l'utilisateur : j'utilise des std::fstream et j'ai rien à fermer.

Je vois pas comment on peut traiter la cause dans le dtor dès que c'est un poil technique, par exemple rollback de transaction ou refermer/compresser/écrire une archive zip sur le disque.

C'est pourtant assez clair, justement : soit l'opération de rollback/compression/écriture a une garantie de succés, et on la met dans le destructeur sans problème ; soit elle peut échouer, et elle n'a rien à y faire.

Typiquement, un rollback de base de données c'est censé être fait automatiquement il "suffit" de ne pas soumettre des transactions qui laissent la base de données dans un état qui ne nous va pas. Si on veut écrire des fichiers dans le destructeur, on peut mais on abandonne à la première exception rencontrée, il ne faut donc pas que ce soit essentiel au fonctionnement du programme.

sauf que ça te donne toujours pas d'action alternative, juste une espèce d'alarme où tu peux rien faire.

 
bah ça dit que potentiellement tes données se sont mal écrit donc la suite est classique:
- en lecture tu peux ignorer l'erreur (ou juste la logger)
- si c'est un service tu peux logger l'erreur et si les données sont encore disponibles en mémoire réessayer la procédure d'écriture.
- si c'est un GUI: signaler l'erreur, proposer à l'utilisateur de rebrancher la clé USB ou le lecteur réseau et réessayer l'écriture du fichier, ou proposer d'enregistrer à un autre endroit  
 
etc...
 
exactement pareil qu'en cas d'erreur de write

de manière un peu bizarre, dans côté dev tu sais pas trop si c'est un lecteur USB ou un lecteur réseau. Et si le close a foiré, tu peux rien faire de ta connexion, au mieux il faut en rouvrir une.

C'est exactement ca mon souci en général : si t'es pas capable de réagir proprement à une erreur, ben ouais, c'est pas super utile de tester, à part juste pour afficher un message d'erreur à l'utilisateur.
Si tu arrives à la fin de ta limite d'écriture sur ton disque, tu t'attends quand même pas mal à avoir des fichiers foireux

Un peu mou de la bite, je m'attendais à mieux vu le pédigree de l'auteur

 
ouais, y'a quelques longueurs, mais c'est quand même bien foutu.
 
Un peu caricatural, mais bn.

 
zip tu peux aussi rollback tes modifications et laisser l'archive source intact au lieu de tout péter par exemple

 
Tout dépend d'à quel point tes données sont critiques, comme toujours. Si t'es parti sur un append de ton fichier, tu l'as dans l'os pour rollbacker, après, si tu remplis un autre fichier pour remplacer, ouais, ca peut se gérer, c'est sur

bonne chance avec un manuel comme ça :
http://linux.die.net/man/2/close
parce que tu sais pas si le fichier a réellement été fermé ou pas, si des opérations n'ont pas été partiellement effectuées (et cerise sur le gateau avec la remarque sur fsync() du coup t'as même pas d'opération atomique pour flusher et fermer un descripteur)

je sais pas comment ils font les gens sérieux genre sqlite etc.

 
intéressante question. A la base, il y a des alternatives à fopen/fclose ?

je pense que tu peux faire tes syscall toi-même, mais il faut écrire une couche par OS. Sinon, peut-être que POSIX a une meilleure doc sur les garanties de close().

 
ça revient quand même à réinventer la roue sans aucune garantie d'avoir un truc plus reliable à la fin (le contraire est même ultra-probable).

Bah de toutes façons dans une situation comme ça, le problème c'est de lire la tonne de doc pour capter toutes les assomptions et garanties du code de la lib / os

je crois que tu n'as pas très bien compris le principe du fsync: après un fsync réussi tant que tu n'écris rien après ton fichier est consistant sur le disque. Donc ton close() n'a pas trop de raison de foirer et même si il foire vu que ton fichier est consistant sur le disque et que tu n'as rien écris après alors tu t'en branles.