Bonjour,
 
J'ai une classe singleton qui me permet d'écrire des logs dans une console.
Dans mon appli je charge dynamiquement du code (dll), et cette dll écrit des choses via la classe de log.
Le problème est que ce code chargé dynamiquement crée une nouvelle instance de mon singleton, au lieu d'utiliser celle déjà existante.
 
Y a-t-il moyen de régler ce problème ?

ne pas utiliser de singleton. c'ets l'anti-pattern absolu qui ne résout jamais rien.

Ok, tu aurais une piste pour faire ce que je veux ?

 
C'est l'exemple canonique du pattern dont certains abusent, je suis d'accord.  Mais anti-pattern absolu me semble trop fort.  Surtout dans ce contexte qui est un des cas ou le singleton a du sens (meme si personnellement j'ai tendance a proposer une API avec une classe monostate ou meme simplement procedurale plutot que d'exposer le singleton qui se trouve eventuellement derriere)
 

 
Sans voir ton code, c'est difficile de trouver la cause.  En prime, suivant comment tu implementes le singleton les differences entre DLL de Windows et objets partages d'Unix entrent peut-etre en jeu et je connais mal Windows.

Je code sous Windows effectivement, et le code de mon singleton est vraiment basique, du genre :
 

Si le code suivant impl est dans un CPP et linke qu'une fois, je ne vois pas de probleme.  (Il me semble me souvenir, mais je peux me tromper, que ca implique sous Windows qu'il soit dans une DLL a part du programme principal et de la DLL chargee dynamiquement et qu'il faut aussi une serie d'annotation pour que les fonctions publiques soient bien exportees -- sous Unix en general tout est exporte par defaut)

Merci beaucoup, ça fonctionne. Mon Logger était compilé dans une lib statique.

http://pocomatic.com/docs/whitepapers/pococapsule-cpp/  ?

Intéressant, je note !

comment gérer les classes ou l'on ne veut qu'une seule instance dans le programme , et où l'on souhaite y accéder à droite et à gauche ? le singleton
est tellement pratique dans ces cas là

tu veux une seule instance ? tu n'en crée que une.  
Tu veux l'utiliser à droite à gauche, et bien, les paramètres de fonctions/méthodes ne sont pas la pour rien.

 
Pour un logger?

comme je l'aideja dit (ici ou ailelurs je ne sais plus) , le logger c'ets bien le seul cas ou le singleton a peut etre un sens. Encore que pour moi, les logger j'aime bien en avoir diverses instacnes avec diverses réglages etc ...

 
 
Les factories sont un autre cas.  Un gestionnaire de configuration aussi.
 
Si tu as un interpreteur embarque dans ton application, il est aussi souvent unique ou du moins il y en a un principal qui est reference un peu partout (meme si je ne concevrais pas un interpreteur comme singleton, je vois bien un singleton permettant d'y acceder).
 

 
Je prefere un argument au log qui choisit une configuration nommee pour ca.  Entre autres parce que passer tes differentes instances configurees differemment un peu partout est encore plus lourd que d'y passer un logger unique.

autrement dit en quoi le pattern est il l'atii pattern tant décrié

en ce que les gens en mettes partout ou il n'a pas de sens. Donc en general, on réfléchi avant de vraiment trouver que y a que ça pour résoudre un probleme.

dans mes applis bien souvent j'ai ma classe main qui est un singleton dans laquelle j'aggrège d'autres objets, tout ces objets n'ont vocation qu'à avoir une seule instance dans le programme, comme une liste de connexion , une connexion à une Bdd etc, ça marche bien en multi thread et c'est très pratique de pouvoir avoir accés simplement à tous ces objets dans le thread de la gui dans les thread socket etc
 

tu fait du JAVA donc ...

 
pourquoi?

tu parles d'une classe main ...

une classe main = une classe centrale, qui contient en membre donné tous les objets importants de l'appli, c'est une manière révolutionnaire de faire les applis imo

 
Un truc qui est déclaré en global mais qu'on n'a pas le droit de faire mais qui marche trop bien?

ouais ca evite de reflechir au design, tu peux ecrire du C++ qui ressemble à du C moche. Quelle avancée

ça évite de faire un design foireux inutilement...là t'as un design simple fiable efficace en MThread, qui fait ce qu'on lui demande, facile à faire évoluer bref wtf with singleton
 
PS : philosophie qui convient certainement en environnement où le temps de développement est cours et les évolutions fréquentes

des boites de dev de qualité ça madame

des boites où la qualité du dev à peu d'importance puisque dans 2 ans ça sera à jeter, seul importe la fiabilité maximal et le temps de dev le plus court possible. chose que le singleton à comme avantage