Bonjour à tous,
 
Derrière ce titre un peu racoleur ce cache un problème assez amusant (ou pas, ça dépend du point de vue).
 
J'ai une classe qui ressemble à ça :
 

 
L'idée c'est d'avoir un logger spécifique à Qt qui va catcher les messages de Qt et les "logger" quelque part.
Voici l'implémentation (j'ai un peu simplifié) :
 

 
Or, le constructeur de QtLogger n'est jamais appelé ! À mon avis GCC doit shooter la variable me en se disant qu'elle n'est jamais utilisée. Si j'appelle artificiellement QtLogger::me.log(..) quelque part au hasard dans mon code alors le constructeur est appelé correctement.
 
Quelqu'un aurait une idée !? Est-ce une comportement normal ?

Je parie que tu as mis le fichier objet généré dans une bibliothèque statique?
 
Si c'est bien le cas, le problème est que tu n'as pas compris comment les bibliothèques statiques fonctionnent: l'éditeur de liens extrait de celles-ci les objets fournissant des symboles n'ayant pas de définition au moment où la bibliothèque est examinée.  Comme ce n'est pas le cas -- tu désires que tout fonctionne par effet de bord de l'initialisation -- le fichier n'est pas extrait.  Quand tu ajoutes une référence artificielle, l'éditeur de liens a une raison d'extraire le fichier objet.

Hello, merci pour ta réponse, effectivement j'utilise ce code dans un bibliothèque statique. Je vais me renseigner sur le sujet, ne m'étant jamais vraiment intéressé au processus derrière l'édition de liens.
 
Existe-il une solution à mon problème ou dois-je revoir mon approche ?

stocke un shared_ptr sur ton logger et lors du premier appel de log(), test si il est construit ou pas. Le cas echeant , construit le dynamiquement.

Oui mais dans mon cas 'log' n'est appelé quand dans le cas où un objet QtLogger a été construit puisque c'est à ce moment là qu'est posé le handler. Je crois que je vais déplacer 'static const QtLogger me' dans une autre unité de compilation... c'est un peu zarb.

Il y a différentes solutions:
- ne pas mettre le code dans une bibliothèque statique
   - le mettre dans une bibliothèque dynamique
   - mettre le fichier objet réalisant l'enregistrement directement sur la ligne de link
- référencer l'objet
   - par un appel à une fonction factice ou réalisant l'enregistrement dans main
   - en jouant sur les options de l'éditeur de liens (--undefined avec l'éditeur de liens de GNU)

deja, moi, les static globales dans des lib
je comprends pas pourquoi tt le monde pense que le logger doit etre global vv

 
Je crois que tu donnes la réponse dans ta question.  Si tu penses au logger plutôt qu'à un logger, c'est normal qu'il soit global.
 
D'après mon expérience, c'est quand même mieux que la situation où on a partiellement prévu d'en avoir plusieurs mais en pratique il n'y en a qu'un et le code suppose que les différents manière possible d'accéder à un logger sont équivalentes.  Dans le premier cas, on peut planifier le changement, dans le second, on vit l'illusion qu'il sera plus facile que dans le premier alors que si c'est vrai, c'est marginal et par hasard.

bah dans ttes mes applis, j'ai une collection de loggeur ou je veux changer dynamiquement ou ca part (ficheir, console) en fonction du composant logger, de l'algo etc.
 
en gros j'ai des log(message,logging_sink);
 

J'ai pas dit que j'approuvais le raisonnement, simplement je le comprends.
 
Tout comme je comprends le raisonnement dans le cas présent -- qui n'est pas tant lié aux logs qu'à l'enregistrement automatique de certaines instances -- mais ne l'approuve pas.  Mon expérience me dit que se fier à ces enregistrements entraîne des problèmes d'ordre et de dépendances subtiles.

ok ^^

Merci pour vos commentaires, j'ai choisi la méthode de l'appel à une méthode factice.