Bonjour,

Comme annoncé dans le titre j'ai créé une classe qui surdefinie <<. Pour cela je l'ai fait dériver de streambuf et ostream.

Tout ce passe correctement lorsque j'utilise 1 <<. Si je les place en cascade, je ne recupere pas la chaine totale mais la surchage de l'operateur << est executée pour chaque cascade.

J'ai veinement cherche de la doc sur google mais tres peu de sites traitent de la surcharge des operateurs de flux. Et encore moins l'abordent en profondeur. Par contre les bases du langage 'y en a des tonnes!
J'ai qqs livre sur C++ mais cette notion est aussi tres peu expliquée.

Si qq'un connait une url ou peut m'expliquer à l'aide d'un exemple, je suis preneur.

Merci d'avance pour vos remarques.
--
Gosseyn

Je ne suis pas sûr de suivre... Tu peux laisser un bout de code en pointant le problème ? Je me suis un peu amusé à surcharger <<, moi aussi, je vais peut-être pouvoir t'aider !

En fait je voudrais etendre les fonctionnalités de clog pour qu'il envoit les données au daemon syslod (sous Unix/linux).
par exemple:
mylog(facility, errorLevel) << "problem: " << "ben alors!" << endl;
ou bien
mylog(errorLevel) << "problem: " << "ben alors!" << endl;
ou encore
mylog<< "problem: " << "ben alors!" << endl;

Je simplifie mais la declaration est comme cela:

class mylog {
MyLog &operator()(string p_ident, Class p_class= classUser, Level p_level = levelError);
MyLog &operator()(Level p_level);
MyLog &operator<<(const string&);
};

la surdefinition de l'operateur () intialise des variables de la classe et << appel la fonction syslog(). Lorsque l'on place des "<<" en cascade, syslog est appelé plusieurs fois donc plusieurs lignes dans le fichier de log au lieu d'avoir une seule et meme entrée/ligne.

J'ai tenté de dériver
class MyLog : protected std::streambuf, public std::ostream mais je n'ai pas bcp avancé car si la classe supporte maintenant les '<<' en cascades, je ne sais pas comment récupérer la chaine finale.
Actuellement je m'oriente plutot sur strstream et associée.

Je suppose que ce n'est pas vraiment les streams standards qui t'intéressent - tu veux juste passer du texte (paramétré) à syslog() ? Tu peux dériver de std::stringstream (dans <sstream>), qui proposent la méthode "str()" qui renvoie la string associée au flux. Dans le destructeur, appelle syslog avec le texte retourné par str().c_str(), et hop !
Tu as juste à ajouter des variables membres qui stockent les différents paramètres pour syslog et la forme à utiliser, variables qui sont initialisées par le contructeur. Tu n'as alors plus besoin de l'opérateur ().

edit 19: un inconvénient à tout ça, c'est que tu construis et détruis un objet à chaque fois que tu entres un ligne de journal...

Récupérer la chaine dans le destructeur implique que l'objet doit etre detruit pour que le log soit ecrit. Il faut donc le placer dans un bloc de code assez petit ou appelé explicitement "delete". J'ai un peu "peur" de louper des logs avec ça.

J'ai tenté de surdefiir la methode stringbuf::overflow() qui est appelé lors d'un <<. Cela evitait d'attendre le destructeur pour récupérer la chaine mais sans succés jusqu'à present.

Je pense que je vais me contenter d'un << sans offrir la possiblité de les mettre en cascade pour l'instant. Je voyais aussi cette classe comme un moyen de travailler avec les flots mais cela reste assez complexe pour créer ses propres classes les exploitant en partculier si on veut récupérer la chaine de caractère.
Merci de ton aide.

Tu pourrais aussi (re)définir un modificateur de flux, comme flush, qui serait appelé dans le destructeur ou quand tu le précises.

oui, j'y ai aussi pensé mais s'il faut appeler une fonction apres le "<<", cela presente moins d'interet. Autant appeler directement une fonction qui ecrit dans les logs.... Je pense avoir trouvé un compromis entre l'objectif (faire comme clog) et mes compétences techniques me permettant de l'atteindre. ;-)

Je n'ai jamais utilisé clog, mais il me semble qu'il n'est pas tamponné, donc à chaque <<, un bout de chaîne est envoyé.

sauf erreur ma part, clog EST tamponné. C'est ce qui le différencie de cerr.

http://developers.sun.com/tools/cc/documentation/ss10_docs/mr/man3c++/clog.3.html

on dirait bien que j'ai confondu