ofstream static en logging dans une bibliothèque

Version imprimable

Bonjour,

Lors du développement d'une petite bibliothèque, je souhaite mettre en place un petit système de logging, et me suis heurté au problème suivant.
Précision: je voulais un petit truc simple, sinon, je sais , y'a boost::logging
http://torjo.com/log2/doc/html/index.html

Contraintes:
-je ne veux pas utiliser le flot standard stderr (via cerr), qui doit être réservé à l'appli principale (donc pas de freopen()...)
-je ne veux pas que l'ouverture de ce fichier se fasse via l'appel d'une fonction Start() ou un truc du genre. Il faut que le fichier s'ouvre "tout seul" dans toute application qui est linkée avec cette bibliothèque.

L'idée sur laquelle je suis parti est d'ajouter une classe A, contenant uniquement un attribut statique, déclaré en public, qui sera le ofstream qui servira pour logger des trucs. (bon, y'aura d'autres trucs, mais je limite à l'ECM)
Cette classe ne sera jamais instanciée (=> constructeur en private)
Code:

1 2 3 4 5 6 7 8 // fichier a.hpp class A { public: static ofstream ferr; private: A() { assert(0); } // on sait jamais, avec les ordinateurs... };
Code:

1 2 3 // fichier a.cpp #include "a.hpp" ofstream A::ferr;
L'idée, c'est que je puisse de partout faire:

Code:

A::ferr << "ici, y'a un problème\n";

Problème : comment faire en sorte que le fichier s'ouvre tout seul ?

La solution que j'ai trouvée: créer une classe parallèle, qui est instanciée aussi en static dans A, et dont le constructeur ouvre ferr:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class OuvreLog { OuvreLog() { A::ferr.open( "mon_log.txt" ); // plus la vérification kivabien, évidemment A::ferr << "Hello\n"; } ~OuvreLog() { A::ferr << "bye\n"; A::ferr.close(); } };
Mais si j'ajoute un membre statique de type OuvreLog dans la classe A, alors je tombe sur un problème de déclaration multiple:
- la classe OuvreLog a besoin de connaitre la classe A
- la classe A a besoin de connaitre la classe OuvreLog

Ma solution (pour l'instant): créer en statique dans A non pas un objet, mais un pointeur sur l'objet:
Code:

1 2 3 4 5 6 7 8 9 // fichier a.hpp class OuvreLog; // déclaration d'existence class A { public: static ofstream ferr; static OuvreLog* ol; };
et dans le .cpp, initialiser le pointeur en créant un objet:
Code:

1 2 3 4 // fichier a.cpp #include "a.hpp" ofstream A::ferr; OuvreLog* A::ol = new OuvreLog();
Et ca fonctionne... à moitié !
En effet, dans ce cas le destructeur de OuvreLog n'est jamais appelé, et le fichier pas fermé.

Bon, je sais que de toute façon, un bon OS va fermer tous les handle de fichier encore ouverts lors de la terminaison d'un programme, mais j'aimerais bien quand même fermer proprement mon fichier moi-même (ne serait-ce que pour vérifier l'arrêt correct).

Quelqu'un aurait une idée ? Ou alors une façon complètement différente de procéder ?
Merci.

Bonjour et bienvenu,
Rapidement :
1 remarque : la dépendance croisée est un indice d'un petit problème de conception.
2 solutions :
-> Utiliser un pointeur intelligent au lieu d'un pointeur nu :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <iostream>
#include <boost/shared_ptr.hpp>
 
struct A
{
   public:
   A(){std::cout<<"Construction de A"<<std::endl;}
   ~A(){std::cout<<"Destruction de A"<<std::endl;}
};
 
static const boost::shared_ptr<A> gs_a(new A);
 
int main()
{
   return 0;
}

-> Ajouter une instance static privé de A qui ouvre et ferme ton fichier :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>
#include <fstream>
 
class A
{
    public:
       A& instance()
       {
          return a;
       }
        std::ofstream ferr; // attetion, n'est plus statique sinon problème car on ne sait ps dans quel ordre sont instancié les éléments.
    private:
        A() { ferr.open(/*...*/); }
        ~A(){ferr.close(); }
        static A a;
};
A A::a;

30/10/2009, 17h52
3DArchi
Sur ton exemple de base, à la place de :
Code:

1 2 private: A() { assert(0); } // on sait jamais, avec les ordinateurs...
Tu peux faire :
Code:

1 2 private: A();
Sans bien sur le définir. Ce qui provoquera une erreur de lien si d'aventure quelqu'un s'arroge le droit de quand même vouloir créer un A
31/10/2009, 00h28
akirira
Citation:
Envoyé par 3DArchi

Sur ton exemple de base, [...]
Tu peux faire :

Code:

1 2 private: A();

Sans bien sur le définir. [...]
Pas mal, assez bien vu, comme ça, l'erreur est effectivement détectée à la compilation, et non pas au runtime.
Et sur l'utilité d'une telle "protection", on n'est jamais à l'abri d'une déclaration d'amitié qu'on aurait laissé trainer, et qui violerait le "private"... Donc, mieux vaut se prémunir.
31/10/2009, 00h41
akirira

Citation:

Envoyé par 3DArchi

Bonjour et bienvenu,

Merci!

Citation:

Envoyé par 3DArchi

Rapidement :
1 remarque : la dépendance croisée est un indice d'un petit problème de conception.
2 solutions :
-> Utiliser un pointeur intelligent au lieu d'un pointeur nu :
-> Ajouter une instance static privé de A qui ouvre et ferme ton fichier :

J'ai pas boost sous la main sur la machine où je suis, mais j'ai essayé la 2è solution. En fait, je ne savais pas qu'on pouvait instancier en static dans une classe un objet... de la classe elle-même! (vu qu'en allocation automatique, on ne peut pas)

Petite correction: pour pouvoir accéder à 'ferr', il faut le déclarer en public. Et à l'utilisation, on doit alors écrire:

Code:

A::a.ferr << "mon texte\n";

ce qui est un peu plus lourd, mais de toute façon, ça sera masqué dans une macro.

Et j'ai pas bien compris l'intérêt de la méthode instance().. Ou alors y'a un truc qui m'a échappé ?

Merci, en tout cas, j'essaye la première solution demain.
31/10/2009, 00h59
Goten

Une classe de log est un excellent candidat au titre de singleton. C'est ce que t'as montré 3Darchi me semble.
Attention il faut un singleton bien pensé toutefois, (celui de loki est bien pour ça, le phoenix singleton)
01/11/2009, 11h00
akirira
Citation:
Envoyé par 3DArchi

Tu peux faire :

Code:

1 2 private: A();

Sans bien sur le définir.
Je rebondis sur ma propre réponse à cette suggestion: dans l'idéal, il faudrait aussi déclarer de la sorte le constructeur de recopie ! :
Code:

1 2 3 private: A(); A( const A& );
01/11/2009, 21h38
3DArchi
Citation:
Envoyé par akirira

Je rebondis sur ma propre réponse à cette suggestion: dans l'idéal, il faudrait aussi déclarer de la sorte le constructeur de recopie ! :

Code:

1 2 3 private: A(); A( const A& );
Autant aller jusqu'au bout : F.A.Q. : Comment rendre une classe non copiable ?