Problème de copie avec fstream

Bonjour,

J'ai une structure définie comme ceci :

Code:

---

1 2 3 4 5

struct X { std::ofstream file; // ... };

---

et une classe Y qui stocke des X :

Code:

---

1 2 3 4 5

class Y { private: std::unordered_map<std::string, X> data; };

---

Mon soucis, c'est que lorsque je veux créer un nouveau X et le ranger dans data, le compilateur m'en empêche :

Citation:

---

error: use of deleted function 'X& X::operator=(const X&)'
note: 'X& X::operator=(const X&)' is implicitly deleted because the default definition would be ill-formed:
error: use of deleted function 'std::basic_ofstream<char>& std::basic_ofstream<char>::operator=(const std::basic_ofstream<char>&)'

---

Comment puis-je m'en sortir ? J'aimerais pouvoir faire ceci :

Code:

---

1 2	Y y; y.add_X ("ID", X(/* ... */));

---

Comment puis-je le créer sans copie ? (j'utilise un mingw64 avec gcc 4.7).

Il faudra utiliser un pointeur quelque part. Soit pour stocker le fstream dans X, soit pour stocker le X dans la map.

Ton gcc gère la move semantic. Il est impossible de copier un fstream, mais il est possible de le déplacer.

Déjà pour activer les nouveautés du C++11, il faut compiler avec le flag -std=c++11

Ensuite, il faut que ton objet contenant un flux soit lui même déplaçable. Et finalement, pour mettre dans ta map, que tu ne génère pas de copie, mais un déplacement.

Peut-être que si tu montre un peu plus de code il sera possible de voir où ça coince ?

Je compile déjà en C++11, pour pouvoir utiliser les unordered_map sans boost.

Voici la classe X (partiellement) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

struct LogLevel { LogLevel (const std::string & file_name, const std::string & msg_header = "[TRACE]", const std::string & date_format = "[%d/%m/%y - %H:%M]"): file (file_name, std::ios::app), header (msg_header), file_name (file_name), date_format (date_format) {}   ~LogLevel () { if (file.is_open()) file.close(); }   std::ofstream file; std::string header, file_name, date_format; };

---

Et la classe Y (partiellement) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class Logger { public: // -- CONSTRUCTORS Logger () = default; Logger (std::initializer_list <LogLevel> levels);   public: // -- DATA MANAGEMENT void register_level (const std::unordered_map<std::string, LogLevel> & levels) { for (auto it = levels.begin() ; it != levels.end() ; ++it) this->levels[it->first] = LogLevel (it->second.file_name, it->second.header, it->second.date_format); // Problème ici }   private: // -- DATA std::unordered_map <std::string, LogLevel> levels; };

---

J'aimerais pouvoir faire ça au final :

Code:

---

1 2 3 4

logger.register_level ( {"UN_NIVEAU", LogLevel ("./logs/")}, {"UN_AUTRE", LogLevel ("./logs/other/")} );

---

J'ai pensé utiliser un emplace, mais j'ai des tas d'autres erreurs.

Je n'ai pas trop l'habitude de la move semantic, devant compiler sur des antiquités, mais je dirais à vue de nez :

- Le destructeur dans LogLevel empêche la génération automatique d'un mode constructor de déplacement ou d'un opérateur= par déplacement. Donc soit tu supprimes ce destructeur (qui de toute façon n'a pas l'air utile, a moins que le vrai code fasse d'autres choses), soit tu déclares et défini ces deux opérations (éventuellement avec du =default, pour ne pas avoir à les implémenter). Ta classe est désormais movable

- Comme dans ta ligne this->levels[it->first] = LogLevel (it->second.file_name, it->second.header, it->second.date_format);, ce que tu ajoutes dans ta map est un temporaire, le compilateur devrait choisir la version qui déplace, donc ton code devrait compiler.

- Par contre, avec ce code, tu te retrouves à ouvrir deux fois le fichier de log simultanément, la seconde ouverture va probablement échouer, et donc le flux être dans un état d'erreur, et c'est celle là qui importe... Il serait donc probablement préférable de modifier ta fonction pour qu'elle prenne tes données par r-value ref aussi, prenant alors possession de celles ci, et t'obligeant lors de l'appel à lui passer des données temporaires qui ne seront plus utilisées après.

Je te remercie de tes réponses, cependant :

- La mise en commentaire de mon constructeur ne change strictement rien. Par ailleurs, j'ai lu à plusieurs reprises que le destructeur d'un of/if/fstream ne fermait pas le fichier, et que donc il fallait le faire manuellement.
J'ai donc ajouté les deux operations en mode = default; mais elles sont implicitement deleted par mon compilateur car il semblerait que mon ofstream n'ait pas de sémantique de déplacement.

- A cette ligne précise, mon compilateur persiste à vouloir utiliser l'operator= (const ofstream &) plus que la version move, je suppose donc qu'elle n'existe pas.

- De quelle façon puis-je arriver à ce résultat ? J'ai besoin de passer par le constructeur par initializer_list de mon unordered_map pour faire ce dont j'ai besoin, donc je ne peux pas me passer de celle-ci.

Malheureusement, à en croire la page GCC C++0x Library Features item 27.9

Citation:

---

27.9 - File-based streams - Partial - Missing move and swap operations

---

Du coup impossible de déplacer des fstream avec gcc 4.7...
C'est quand même fort de café quand on sait que la move semantic et les rvalue reference sont implémentés dans le compilateur depuis 2008 !! (gcc 4.3)

Citation:

---

Envoyé par Nekkro

Je te remercie de tes réponses, cependant :

- La mise en commentaire de mon constructeur ne change strictement rien. Par ailleurs, j'ai lu à plusieurs reprises que le destructeur d'un of/if/fstream ne fermait pas le fichier, et que donc il fallait le faire manuellement.

---

Non, un flux est automatiquement fermé quand il est détruit, et automatiquement détruit quand on quitte la portée dans laquelle la variable correspondante est déclarée ;)

Ainsi, l'accolade servant de portée, on peut parfaitement écrire un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int main() { cons char * str="fichier.txt"; { std::ofstream file(str); // pas besoin de file.open() car le constructeur utilisé ouvre // d'office le fichier // succession d'écritures } { std::ifstream file(str); // pas besoin de file.open() car le constructeur utilisé ouvre // d'office le fichier // succession de lectures } return 0; }

---

qui va compiler et fonctionner sans le moindre problème ;)

Ce code, bien que simple est riche en enseignements, car, il nous permet de constater

1. Que bien que j'utilise (intentionnellement pour l'exemple ;) ) deux fois le même nom de variable (file, en l'occurrence), le compilateur ne se plaint absolument pas d'une déclaration multiple de variable, car la variable file n'existe chaque fois qu'entre sa déclaration et l'accolade fermante dans laquelle elle a été déclarée
2. Que le(s) constructeurs de fstream prenant en premier paramètre le nom de fichier ouvrent automatiquement le fichier dans le mode correspondant (lecture pour ifstream, écriture pour ofstream)
3. Que, si l'on ne précise pas d'argument supplémentaire, les flux sont ouverts en "mode texte" (par opposition au mode "binaire")
4. Que dés que le flux est détruit, le fichier est correctement fermé (autrement, l'exécution planterait lorsqu'on essayerait d'ouvrir le ofstream)

Citation:

---

J'ai donc ajouté les deux operations en mode = default; mais elles sont implicitement deleted par mon compilateur car il semblerait que mon ofstream n'ait pas de sémantique de déplacement.

- A cette ligne précise, mon compilateur persiste à vouloir utiliser l'operator= (const ofstream &) plus que la version move, je suppose donc qu'elle n'existe pas.

---

cf la réponse de Arzar, je ne connais pas non plus bien la move semantic :aie:...

Vérifies peut etre du coté de Gcc 4.8.xx :question:

Citation:

---

- De quelle façon puis-je arriver à ce résultat ? J'ai besoin de passer par le constructeur par initializer_list de mon unordered_map pour faire ce dont j'ai besoin, donc je ne peux pas me passer de celle-ci.

---

Restes seulement bien dans un environnement utilisant C++11 ;)

Par contre, travailles peut etre "à l'ancienne" en ce qui concerne les flux ! :
Depuis toujours (donc, depuis bien avant l'introduction de la sémantique de mouvement ;) les flux ne sont pas copiables.

l'une des solutions envisageables est donc d'ouvrir le fichier (en mode "append" !! ) "à la demande" (comprends : chaque fois que l'on a besoin d'y écrire quelque chose), et de le refermer une fois que l'on a fini d'y écrire ce que l'on devait y écrire ;)

Pour y arriver, il "suffit" que ta classe maintienne non pas le flux mais bien le nom du fichier à utiliser, ce qui fait que ta classe X pourrait ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class X { public: X(std::string const & filename):filename_(filename){} /* transmettons un "range" de chaines de caractères correspondant   * aux informations à écrire dans le fichier   */ template <iterator> void write( iterator begin, iterator end) { std::ofstream ofs(filename_,std::app) while(begin != end) { ofs << *it<<" "; } ofs<<std::endl; } private: std::string filename_; };

---

L'autre solution consiste à garder le flux ouvert en permanence et à en éviter la copie.

Pour éviter la copie d'une variable lorsqu'on la transmet à une fonction, on utilise, tout simplement, une référence sur cet objet car une référence peut parfaitement etre membre d'une classe, pour autant qu'elle soit définie dans le constructeur :D

Il y a "à boire et à manger" dans les deux solutions, car la première risque de "plomber" les performances chaque fois que tu voudra logger quelque chose (il faut compter le temps d'ouverture et de fermeture du fichier pour chaque écriture :aie:), mais elle permettra, en échange, de pouvoir lire le fichier log alors que l'application tourne (ce qui peut, dans certaines situations, etre intéressant quand meme :D )

La deuxième solution éviterait les ouvertures et fermetures continuelles de fichier (et ferait donc potentiellement gagner en performance, au prix d'une utilisation accrue de la mémoire) , mais, par contre, empêcherait l'ouverture du fichier par une application externe tant que l'application tourne.

de plus, il n'y a que deux solutions pour rendre la classe Logger responsable de la durée de vie des flux:

Soit tu crées un membre de type std::ofstream par flux envisagé (et donc par LoggerLevel), mais tu contreviens alors à l'OCP (Open / Close Principle) dans le sens où tu devras rajouter "manuellement" le membre dans la classe Logger

Soit, tu utilises l'allocation dynamique de la mémoire pour créer les flux à la demande et tu maintiens une liste de pointeurs sur ces flux au niveau de ta classe Logger (quitte à passer "ce qui est pointé par le pointeur" au constructeur de ta classe LogLevel ;) ) mais il faut alors s'assurer que la mémoire allouée aux flux sera libérée en temps et en heure.

Un petit tour du coté des smart_pointer fournis par C++11 devrait, en cela, te faciliter un peu la vie ;)

Citation:

---

Envoyé par Arzar

Malheureusement, à en croire la page GCC C++0x Library Features item 27.9

Du coup impossible de déplacer des fstream avec gcc 4.7...
C'est quand même fort de café quand on sait que la move semantic et les rvalue reference sont implémentés dans le compilateur depuis 2008 !! (gcc 4.3)

---

Tu te proposes pour faire un patch ? :mouarf:

Merci beaucoup pour cette réponse complète, Koala01 !

Il va falloir que je revoie absolument toute ma gestion parce qu'apparemment mon compilateur ne reconnait pas cette syntaxe :

Code:

---

1 2 3 4

logger.register_level ( {"UN_NIVEAU", LogLevel<> ("./logs/log.txt")}, {"UN_AUTRE", LogLevel<LogPolicy::FOLDER_POLICY> ("./logs/other/")} );

---

Comme étant celle appelant le constructeur implicite de la unordered_map avec initializer_list ... :

Citation:

---

error: no matching function for call to 'Logger::register_level(<brace-enclosed initializer list>, <brace-enclosed initializer list>)'

---

Donc je sais pas trop comment je vais me débrouiller pour pouvoir ajouter d'un coup plusieurs niveaux (c'est un peu comme devoir faire plein de push_back pour initialiser un vector en pre-C++11 ... :/)

J'ai essayé de me rabattre sur l'ajout d'un élément, en virant temporairement le fichier de LogLevel pour me simplifier la tâche, mais même ça, le compilo veut pas =/

Code:

---

1 2 3 4 5 6 7 8

void register_level (const std::string & name, const LogLevel & level) { levels[name] = level; }   // en faisant ça :   logger.register_level ("ALERT", LogLevel ("./logs/log.txt"));

---

Citation:

---

error: no matching function for call to 'LogLevel::LogLevel()'
note: candidates are:
note: LogLevel::LogLevel(const string&, const string&, const string&)
note: LogLevel::LogLevel(const LogLevel&)

---

Pourquoi diable me demande-t-il le constructeur par défaut alors que je passe le LogLevel par référence constante ? (Évidemment si je rajoute le constructeur par défaut, tout va bien, mais j'aimerais bien savoir pourquoi !)

Citation:

---

Envoyé par Nekkro

Merci beaucoup pour cette réponse complète, Koala01 !

Il va falloir que je revoie absolument toute ma gestion parce qu'apparemment mon compilateur ne reconnait pas cette syntaxe :

Code:

---

1 2 3 4

logger.register_level ( {"UN_NIVEAU", LogLevel<> ("./logs/log.txt")}, {"UN_AUTRE", LogLevel<LogPolicy::FOLDER_POLICY> ("./logs/other/")} );

---

Comme étant celle appelant le constructeur implicite de la unordered_map avec initializer_list ...

---

Il ta manque un niveau d'accolades...

Code:

---

1 2 3 4 5

logger.register_level ({ {"UN_NIVEAU", LogLevel<> ("./logs/log.txt")}, {"UN_AUTRE", LogLevel<LogPolicy::FOLDER_POLICY> ("./logs/other/")} } );

---

Sinon, si les flux ne sont pas movable avec ton compilateur, il va alors de falloir passer par une variable membre de type unique_ptr<ofstream> dans LogLevel, soit avec un unique_ptr<LogLevel> dans ta map.

Comble :

Mes unique_ptr ne sont ni copiables ni déplaçable apparemment.

Donc je vais devoir m'en tenir à des ofstream* ...

unique_ptr est parfaitement déplaçable, hein.

Dans ce cas je comprend pas trop pourquoi mon compilateur refuse de compiler lorsque je l'utilise :/

Autre problème tant que j'y suis :

j'ai rajouté cette ligne dans LogLevel :

Code:

---

constexpr static const char * INFO = "INFO";

---

Et impossible de faire :

Code:

---

cout << LogLevel::INFO << endl;

---

car j'ai une undefined reference dessus ...

Une idée ?

constexpr const ?

Il me semble que la syntaxe devrait plutôt être static constexpr char * INFO = "INFO";. Non ?

Après, quand j'ai utilisé gcc4.6 (pas testé 4.7), j'avais aussi des undefined reference's, mais je ne me souviens plus si j'avais réussi à résoudre le problème ou pas.

Après un peu de duckduckgo'ing (oui, c'est moins beau que googling, mais aussi efficace) : http://stackoverflow.com/questions/8...constexpr-char (premier résultat)

En effet ça marche si l'on redéfinit dans le .cpp.

Pour simplifier mes tests, j'ai créé une structure qui ne contient qu'un unique qunique_ptr<ofstream>.

Mais quoi que j'essaye, je n'arrive pas à rentrer une instance de Test dans ma map, même en passant une simple référence.

Donc mon implémentation de mingw64 n'implémente pas encore le move pour mes unique_ptr, je ne vois que ça.

EDIT : En allant chercher dans les fichiers du compilo, je trouve bien un constructeur par déplacement et un operateur de déplacement, mais apparemment je ne sais pas comment faire pour l'utiliser ^^

Autre problème : quand j'utilise const LogLevel & comme paramètre d'une fonction, j'ai une copie qui est faite. J'ai des problèmes à la destruction de la copie et du LogLevel final, donc pour éviter les copies en attendant de pouvoir utiliser le déplacement, je suis obligé de passer par une référence, non constante.

EDIT 2 : Et encore que non en fait, car lorsque la variable qui a servit à être passée par référence est détruite, sa copie dans la map de Logger est aussi détruite, et hop recrash.
Je suis obligé de faire des pointeurs sur LogLevel si je ne veux pas avoir de crash avec l'ofstream et si je ne veux aucune copie où je n'en veux pas.
Bref c'est vraiment trop compliqué pour être honnête.

Ben, il te reste donc l'autre solution : n'avoir, dans le loglevel, que le nom du fichier pour l'ouvrir et le fermer à chaque écriture ;)

De toutes manières, c'est peut etre le plus intelligent, pour un fichier log, car cela te permettra de lire le fichier alors que l'application fonctionne encore et que l'on peut, malgré tout, considérer que tu ne fera pas des écritures ne serait-ce que toutes les secondes :D

Ceci dit, j'aurais tendance à dire que, entre Logger et LogLevel, celui qui va s'occuper d'écrire dans le fichier (et qui en a donc besoin, que ce soit sur une instance de ofstream ou au travers du nom du fichier à ouvrir), c'est Logger, car tu ne vas sans doute pas créer un fichier différent par niveau de log, mais bel et bien placer tous les élément à logger dans un seul et même fichier.

LogLevel n'est là "que" pour te permettre de formater l'information (et surtout pour te permettre de mettre le bon terme au début de la ligne) ;)

Lorsque tu prends un paramètre comme const LogLevel &, il ne devrait pas y avoir de copie. Serait-il possible d'avoir un code minimal reproduisant le bug ?

koala01: Je pense qu'il vaut clairement mieux garder le fichier ouvert. Surtout que -- sous linux en tout cas -- avoir un fichier ouvert par deux processes en même temps n'est pas un souci. D'ailleurs, pourquoi serait-ce impossible quand tail -f existe ?

Par ailleurs, il semble que le compilateur supporte le move d'unique_ptr. Donc c'est probablement une erreur d'utilisation, ce qui est possible à résoudre !

Citation:

---

Envoyé par Ekleog

Lorsque tu prends un paramètre comme const LogLevel &, il ne devrait pas y avoir de copie. Serait-il possible d'avoir un code minimal reproduisant le bug ?

koala01: Je pense qu'il vaut clairement mieux garder le fichier ouvert. Surtout que -- sous linux en tout cas -- avoir un fichier ouvert par deux processes en même temps n'est pas un souci. D'ailleurs, pourquoi serait-ce impossible quand tail -f existe ?

---

Comme tu le dis si bien : sous linux, il n'y a pas de problème... et sous linux, tail -f existe en effet, mais pas sous windows :aie:

Sous windows, Il existe bien quelques applications qui vont, en réalité, créer une copie temporaire du fichier qu'elles utiliseront tant qu'elles doivent y avoir acces (pour éviter de garder le fichier verrouillé trop longtemps, quitte à comparer de temps en temps (assez régulièrement, en fait :D ) le fichier d'origine (ou en fait sans doute son time code ) avec le fichier temporaire qu'elles utilise, mais, si tu ne fais pas de la sorte, le fiichier reste verrouillé tant que l'application qui l'utilise ne l''aura pas fermé :aie:

Ceci dit, il y a très facilement moyen de faire en sorte que la politique d'ouverture / fermeture du fichier log diffère en fonction du niveau de logging souhaité lors de l'exécution ;)

Il peut, par exemple, en effet etre utile de logger toutes les informations en débug, histoire de pouvoir déterminer un éventuel scenario, alors que, d'un autre coté, le log de production peut "se limiter" aux informations de sécurité et de criticité importante ;)

Il ne serait pas particulièrement difficile (pimpl idiome aidant ;) ) de faire en sorte que le logging en debug garde le fichier ouvert et que le logging en prod ne l'ouvre que "à la demande" ;)

Citation:

---

Par ailleurs, il semble que le compilateur supporte le move d'unique_ptr. Donc c'est probablement une erreur d'utilisation, ce qui est possible à résoudre !

---

Ca, c'est une possibilité qui nécessite d'être creusée, mais qui n'est certainement pas sans fondement ;)

Il est temps que je donne un peu plus d'informations, d'autant que j'ai dû affiner mon problème (merci koala).

L'application qui doit utiliser le Logger est une application serveur, donc j'ai besoin de performances particulièrement rapides.
Mais en parallèle, j'ai besoin de pouvoir consulter les logs en même temps que le serveur tourne, afin de ne pas avoir besoin de l'éteindre ou quoi que ce soit de ce genre pour pouvoir consulter des informations critiques.

La particularité de mon Logger et de LogLevel, c'est que certains niveaux sont logués dans un fichier (et dossier) spécifique jour après jour, tandis que d'autres sont logués dans un unique fichier qui ne change pas.

En plus de ça, j'affiche des informations directement dans la console pour lorsque je debug en direct avec le client.

Cela veut dire que plusieurs niveaux peuvent avoir besoin d'un même fichier, ou pas.

Donc il va falloir non pas que j'intègre l'ofstream directement dans LogLevel, mais plutôt que j'y mette une référence.

@Ekleog > J'avais fait en sorte d'afficher quelque chose dans le destructeur de LogLevel, et à l'exécution je voyais bien que lorsque j'exécutais :

Code:

---

logger.register_level ("truc", LogLevel(/* ... */));

---

Le destructeur était appelé, et par conséquent quand l'objet dans ma map était détruit à la sortie du scope, j'avais un crash car deux destructions d'ofstream sur le même fichier.

Pour ce qui est des unique_ptr, je suis presque sûr de mal m'y prendre puisque ça ne marche pas mais que mon <bits/unique_ptr.h> contient bien :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

// Assignment. unique_ptr& operator=(unique_ptr&& __u) noexcept { reset(__u.release()); get_deleter() = std::forward<deleter_type>(__u.get_deleter()); return *this; }   template<typename _Up, typename _Ep, typename = typename std::enable_if <std::is_convertible<typename unique_ptr<_Up, _Ep>::pointer, pointer>::value && !std::is_array<_Up>::value>::type> unique_ptr& operator=(unique_ptr<_Up, _Ep>&& __u) noexcept { reset(__u.release()); get_deleter() = std::forward<_Ep>(__u.get_deleter()); return *this; }

---

J'ai essayé avec une petit structure ne contenant qu'un seul unique_ptr de le rentrer dans une map, mais je ne sais pas quel prototype donner à ma fonction pour que le move soit appelé (à chaque fois il me dit que j'ai pas de constructeur/operateur de copie parce que sinon il serait malformé ...).

koala01: OMG, je ne me souvenais plus que windows était aussi nul que ça ... :aie:
Sinon, c'est vrai qu'un pimpl pourrait servir, mais pour le cas je pense qu'un flag de compilation suffirait -- pourquoi faire un indirection inutile, étant donné qu'après la compilation le comportement est fixé ?

Nekkro:

Si ton serveur tourne sous un linux, tout va bien avec le concept de garder le fichier ouvert.
Si il toune sous windows, et que tu as beaucoup d'informations à logger, ça va être plus dur.
Mais qui a un serveur sous windows ? (/me troll inside)

Sinon, tu dis que pour utiliser plusieurs LogLevel avec le même fichier, il faudra mettre une référence, mais c'est plutôt un shared_ptr qu'il te faudrait ici.

Sinon, logger.register_level ("truc", LogLevel(/* ... */)); va clairement déclencher le destructeur de LogLevel, mais pas à cause de la référence constante : c'est en fait à cause du LogLevel temporaire que tu créées, qui sera forcément détruit à la fin de l'instruction.
Que voudrais-tu que ce code fasse d'autre ?

Citation:

---

Pour ce qui est des unique_ptr, je suis presque sûr de mal m'y prendre puisque ça ne marche pas mais que mon <bits/unique_ptr.h> contient bien :

---

De toute façon, si tu arrives à instancier std::unique_ptr<un_type> ; c'est forcément qu'il a un move-ctor. Sinon, unique_ptr ne servirait à rien.
Quand utilises-tu unique_ptr ? Penses-tu bien à utiliser std::move(ptr) ?

Sinon, une struct de base rentrable dans une map (non testé) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

struct S { std::unique_ptr<int> p; S(std::unique_ptr<int> &&pp) : p(std::move(pp)) {} // Ctor a partir d'unique_ptr S(S &&o) : p(std::move(o.p)) {} // Move-ctor S & operator = (S && o) { p = std::move(o.p); return *this; } };   // ... std::map<int, S> m; m.emplace(1, new int(42)); // Plus certain de la syntaxe d'emplace, a verifier m[2] = S(new int(1337)); // Ou (pas sur) : m[2] = std::move(S(new int(1337)));

---

Citation:

---

Envoyé par Ekleog

koala01: OMG, je ne me souvenais plus que windows était aussi nul que ça ... :aie:

---

Pas nul, différent.

Personnellement, étant plus habitué à windows, c'est le comportement de linux que je trouve rétrograde (plein d'opérations sans API qui obligent à exécuter des lignes de commandes et à parser les résultats, où à parser un fichier de config pour le modifier, pas de gestion de type comptage de référence pour les objets système (sémaphoe, mutex...)). Mais ce sont avant tout des choix de design et de philosophie.

Et puis, sous windows, il est possible d'avoir un fichier ouvert par deux process en même temps (http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx, en particulier le paramètre sharemode), ce n'est juste pas le comportement par défaut (ce que je respecte, car dans le cas général, deux process qui accèdent au même fichier, c'est une corruption qui ne demande qu'à apparaître). Et donc ce n'est pas un comportement facilement utilisable avec les flux C++.

Citation:

---

Envoyé par Ekleog

koala01: OMG, je ne me souvenais plus que windows était aussi nul que ça ... :aie:
Sinon, c'est vrai qu'un pimpl pourrait servir, mais pour le cas je pense qu'un flag de compilation suffirait -- pourquoi faire un indirection inutile, étant donné qu'après la compilation le comportement est fixé ?

---

En fait, Nekkro m'a donné raison avec ses explications complémentaires :P (bon, d'accord, ce n'est qu'un hasard ;) :D )

En effet, en lisant ce qu'il doit faire, je me dis qu'il serait quand meme préférable qu'un Logger ne manipule qu'un seul fichier, et que l'on puisse en profiter pour gérer l'écriture (ou non) en fonction de la criticité...

Bon, on s'écarte un peu du pimpl, mais, au final, on aurait quelque chose qui serait proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

enum LogLevel { ERROR_Critical, // ce qui provoque l'arret du service /* ... quelque niveau d'erreur non critiques */ WARNING, // un avertissement /* éventuellement des niveau d'avertissement */ INFO // juste une information } class Logger { public: static Logger &instance() { static Loger inst; return inst; } class Logger_impl { public: Logger_impl(std::string const & filename):filename_(filename){} virtual ~Logger_impl(){} virtual void write(std::string const &, LogLevel ) = 0; }; void addLogger(Logger_impl * ) { loggers_.push_back(logger); } void write(std::string const & message, LogLevel level ) {   BOOST_FOREACH(Logger_impl * logger, loggers_) { logger->write(message, level); } } private: std::vector<Logger_impl *> loggers_;   Logger(){} ~Logger() { BOOST_FOREACH(Logger_impl * logger, loggers_) { delete logger; } } }; /* plusieurs classes héritant de Logger_impl pour les différentes  * politiques (en terme de gestion du fichier et en terme d'écriture  * selon la criticité)  */   void log(std::string const & message, ErrorLevel level) { Logger::instance().write(message, level); }

---

Je ne suis pas, par nature, très favorable à l'utilisation des singletons, mais, en l'occurrence, je me dis que, dans ce cas particulier, son utilisation peut se justifier ;)

On aurait, au début de l'application quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10

int init() {   Logger::instance().addLogger(new LoggerErrorOnly("Path/To/error.log"); Logger::instance().addLogger(new LoggerUsage("Path/To/use.log"); /* pourquoi pas */   Logger::instance().addLogger(new OutputToConsole(); /* ... */ }

---

et, au niveau de l'utilisation de simples

Code:

---

1 2 3

log("le message de la mort qui tue", ERROR_Critical); /* ou */ log("un autre message", WARNING);

---

En prenant soin de séparer la classe Logger de la fonction log dans les fichiers d'en-tete (et surtout en implémentant les fonctions dans des fichiers d'implémentation et non inline comme je l'ai fait ici ;)), l'utilisation du Logger peut se faire de manière totalement transparente pour tout codeur qui ne va pas jeter un oeil à la fonction main ;)

De plus, comme on travaillerait sur avec des pointeurs sur loggers_impl (et que l'on a clairement déterminé qui s'occupe de les détruire :D), il n'y aurait meme plus le problème d'une éventuelle tentative de copie du fichier, si celui-ci est ouvert au niveau des classes héritant de Logger_impl :D

Merci à tous pour vos conseils et critiques, j'ai finalement résolu mon problème en créant utilisant les unique_ptr<ofstream> que je créais dans Logger plutôt que dans LogLevel.

Voici un petit sample final :)

Code:

---

1 2 3 4 5

Logger logger; logger.register_level (LogLevel (LogPolicy::FILE_POLICY, "./logs/debug.log", Log::DEBUG)); logger.target (Log::DEBUG) << "Un message de test.\n"; logger.register_level (LogLevel (LogPolicy::FOLDER_POLICY, "./logs/debug/", Log::ALERT)); logger.target (Log::ALERT) << "Un message de test.\n";

---