Discussion :

[Feriaman]

Bonjour.

Je cherche � mod�liser une classe qui permettra � mon programme de tracer tout ce qu'il fait.

Je voudrais pouvoir m'en servir comme �a (en gros) :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
LogsManager a;
a->log("Je commençe le programme"); // certains des logs sont statiques
a->log("Zut, j'ai un objet d'id " + id + " qui est négatif"); // mais pas tous
 
// on peut (doit) donner un type à un log
a->log("Je commençe à parser", LogsManager::Parsing);
 
// on peut même en donner plusieurs
std::list<LogsManager::LogsTypes> types;
types.push_back(LogsManager::Parsing);
types.push_back(LogsManager::StrangeData);
a->log("J'ai parsé la valeur " + val + " qui est supérieure à 100", types);

Dans cet exemple, je suppose quelque chose comme :

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
 
class LogsManager
{
public :
	...
 
public :
	enum LogsTypes
	{
		Parsing = 0,
		StrangeData,
		...
	}
	....
}

Ceci ne semble pas pr�senter de grandes difficult�s.
Sauf que cela me chagrine que les types soient aussi dynamiques.

Cela va me donner derri�re une fonction qui aura comme t�te :

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
18
19
20
21
22
23
 
void LogsManager::log(const std::string& log, const std::list<LogsManager::LogsTypes>* types)
{
	if (types)
	{
		std::list<LogsManager::LogsTypes>::iterator it;
		for(it = types.begin(); it != types.end(); it++)
		{
			switch (*it)
			{
				case Parsing :
					...
					break;
				case StrangeData :
					...
					break;
				...
			}
		}
 
		....
	}
}

Et �a ce n'est pas tr�s joli.
J'imagine qu'il existe une chouette solution pour faire cela statiquement, peut-�tre avec un genre de typelist, mais tout ce que je peux imaginer est terriblement compliqu�.

Est-ce que quelqu'un saurait m'orienter vers une solution plus �l�gante ?

Merci par avance

[mchk0123]

C'est l'inconv�nient de programmer en C++ sans jamais avoir vu de vrai code C !

Donc, la solution la plus utilis�e en C (encore valable en C++), c'est de passer par un enum. -> pour les questions l� dessus.

[Mat007]

Enum ??

Je sugg�rerais au contraire de transformer les enums en vraies classes avec du code dedans, quelque chose comme :

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
 
class LogType
{
    void log( ... ) = 0;
};
 
class Parsing : public LogType
{
  ...
};
 
void LogsManager::log( const std::string& log, const std::list<LogType>& types )
{
    for( std::list<LogsManager::LogsTypes>::iterator it = types.begin(); it != types.end(); it++)
        it->log( ... );
}

Ca me parait plus souple quand m�me.
(au passage je pense qu'il vaut mieux plusieurs versions de la m�thode log plut�t que de passer un pointeur sur une std::list pour tester s'il vaut 0 par la suite, mais bon c'est un choix)

Cela dit, comme toujours, peut-�tre qu'une solution (open-source) existante permettrait de gagner du temps ?
Il y a par exemple log4cxx, que je n'ai jamais essay� cela dit, en g�n�ral je ne log jamais rien je ne trouve pas que �a soit tr�s utile comme pratique...

MAT.

[Luc Hermitte]

Ce n'est pas tant des enum que des manipulations de bits dont voulait parler mchk0123. Je me trompe ? Les enums ne sont pas si adapt�s � cela vu que le nombre compos� ... n'est plus du type de l'�num�r�.

Si ces traitements particuliers peuvent �tre r�alis�s avec une m�me fonction (pas d'arguments propres � un traitement) c'est tr�s bien comme �a (les enums)

Etant dans une situation avec des traitements diff�rents � r�aliser selon les destinations, j'ai tendance � plut�t partir sur des syt�mes qui s'utilisent de la sorte.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
LOG( formatter("toto %2 titi %1") % 42 % "tutu" ) 
    .trace("[Nom Fonction]", OPERATION) // fichier de log
    .alarm(CRITICAL, vehicle1) // notification d'un composant particulier
    .logbook(CRITICAL, vehicle1, composantEmeteur, dateBord) // notif d'un autre composant
    .exception(); // throw est un mot clé déjà résérvé
// le code permettant d'arriver à cela n'est pas forcément simple.

Il y a plein de fa�ons diff�rentes de s'y prendre, et je ne trouve pas qu'il y en ait une qui soit meilleure que les autres.

PS: Ces derni�res semaines, il y a eu quelques discussions relatives aux syt�mes de log.

PPS: Je loggue �norm�ment. Il s'agit d'un gros composant multi-t�che qui doit tourner pendant des jours et des jours sans s'arr�ter. D'autant qu'il n'est pas rare que l'on ne dispose plus des binaires associ�s � un crash (-> coredump inexploitable). Bref, il n'y a souvent que cela pour nous aider � diagnostiquer les anomalies de fonctionnement.
Apr�s l'analyse des logs se fait les doigts dans le nez quand on dispose d'un outil adapt� (gvim au hasard )

[mchk0123]

Pour les enums, oui l'utilisation bas niveau se fait � base d'op�rations binaires, mais les enums sont l� pour avoir une s�lection des options sous forme symbolique et pas num�rique (quelques petits pbs. de conversions entre �nums et entier, mais �a reste confin� � l'int�rieur de la classe Log).

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
log.options(Log::no_echo | Log::named_pipe | Log::only_criticals);
log.filename("log.txt");
log.print(format("%s : %s\n", nom_composant, msg));

C'est vrai qu'avec ma solution, je suis obliger de cinder le param�trage du log en 2 : les options d'un c�t� (enums), les valeurs de l'autre (int, string, ...).

Tr�s �l�gante et flexible ta solution Luc Hermitte (j'avais pas penser � utiliser la m�me notion qui existe sur les fstream). :roi2:
Je me la note dans un coin du cerveau !

Sans parler du "%" ! On dirait presque du P.... (je tairais le nom ).
Le C++ n'as pas fini de nous �tonner !

[Luc Hermitte]

Tout n'est pas incompatible.
Ce que j'ai montr�, c'est l'utilisation (au travers d'une macro qui va m�moriser __FILE__ et __LINE__ pour les injecter dans l'exception lev�e). Tu peux en plus initialiser ton loggeur comme il te plait, avant. Voire avoir une option pour logguer via le logger "log".
(Il y a tellement de choix possibles, que j'ai le plus grand mal � d�finir un syst�me de logs v�ritablement g�n�rique)

Le truc est que dans notre application certains messages ne partent que dans l'unique fichier de traces du composant, d'autres sont envoy�s (via Corba) vers un composant (ou l'autre) qui va redispatcher les alertes (typ�es) aux IHMs. Chaque message va avoir son traitement qui lui est propre. Avec les param�tres associ�s.

Du coup, j'ai besoin de param�ter le message dans les fonctions "g�n�riques" qui ont un v�hicule d�ternim� au dernier moment.
Quand le seul choix c'est fichier1, fichier2, ou console, pas besoin de sortir un truc aussi compliqu�.


Pour le %1, ce n'est pas de moi. boost.format propose cela -- autant dire, que le formateur, je ne tiens pas particuli�rement � l'impl�menter personnellement. Et la premi�re fois que je l'avais crois�, c'�tait en TCL.