Discussion :

[akirira]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
// fichier a.cpp
#include "a.hpp"
ofstream A::ferr;

L'idée, c'est que je puisse de partout faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

   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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[3DArchi]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;

[3DArchi]

Sur ton exemple de base, à la place de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[akirira]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[akirira]

Bonjour et bienvenu,

Merci!

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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)

[akirira]

Tu peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    private:
        A();
        A( const A& );

[3DArchi]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    private:
        A();
        A( const A& );

Autant aller jusqu'au bout : F.A.Q. : Comment rendre une classe non copiable ?