je sais que je suis HS avec cette question, mais je n'ai pas trouvé de
réponse ailleurs pour le moment, ce pourquoi je me permets ce petit
travers.
J'ai une classe singleton Montage_Gestion qui se trouve dans une DLL nommé
Montage.
J'ai remarqué le problème suivant:
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une
seule et unique instance de ce singleton, pas de soucis.
Si par la suite je passe par l'application .EXE pour instancier ce
singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il
m'en crée une nouvelle instance.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent
des segments de mémoire différents.
Seulement je ne sais pas comment y remédier.
Est-ce que certains d'entre vous ont déjà eu ce genre de souci?
Et bien sûr l'avez-vous résolu?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alexandre
bonjour,
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une seule et unique instance de ce singleton, pas de soucis. Si par la suite je passe par l'application .EXE pour instancier ce singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il m'en crée une nouvelle instance.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents.
je ne suis pas spécialiste de windows, mais il me semble que c'est le comportement "normal", puisque la DLL pourrait être utilisée par plusieurs applications...
Seulement je ne sais pas comment y remédier.
il faut utiliser un espace "partagé" entre plusieurs processus/applications/DLL... Je suppose que dans les API Win32 il y a ce qu'il faut, utiliser une mémoire allouée avec GlobalAllock (ou un nom comme ça, j'avoue ne plus m'en servir, et j'ai prété mon petzold il y a longtemps...), qui de mémoire retourne un handle (un entier), puis vérrouiller avec GlobalLock pour avoir un pointeur, déverrouiller avec GlobalUnlock puis libérer avec GlobalFree. L'idéal serait de confier tout ce travail à une classe POINTEUR_GLOBAL ou un truc du même genre, et de l'utiliser dans ton singleton...
Est-ce que certains d'entre vous ont déjà eu ce genre de souci? Et bien sûr l'avez-vous résolu?
perso non, c'est juste une idée comme ça. Si ça peut aider... Peut-être sur fr.comp.ms-windows.programmation tu aurais plus de réponses...
bonjour,
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une
seule et unique instance de ce singleton, pas de soucis.
Si par la suite je passe par l'application .EXE pour instancier ce
singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il
m'en crée une nouvelle instance.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent
des segments de mémoire différents.
je ne suis pas spécialiste de windows, mais il me semble que c'est le
comportement "normal", puisque la DLL pourrait être utilisée par plusieurs
applications...
Seulement je ne sais pas comment y remédier.
il faut utiliser un espace "partagé" entre plusieurs
processus/applications/DLL... Je suppose que dans les API Win32 il y a ce
qu'il faut, utiliser une mémoire allouée avec GlobalAllock (ou un nom comme
ça, j'avoue ne plus m'en servir, et j'ai prété mon petzold il y a
longtemps...), qui de mémoire retourne un handle (un entier), puis
vérrouiller avec GlobalLock pour avoir un pointeur, déverrouiller avec
GlobalUnlock puis libérer avec GlobalFree. L'idéal serait de confier tout ce
travail à une classe POINTEUR_GLOBAL ou un truc du même genre, et de
l'utiliser dans ton singleton...
Est-ce que certains d'entre vous ont déjà eu ce genre de souci?
Et bien sûr l'avez-vous résolu?
perso non, c'est juste une idée comme ça. Si ça peut aider...
Peut-être sur fr.comp.ms-windows.programmation tu aurais plus de réponses...
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une seule et unique instance de ce singleton, pas de soucis. Si par la suite je passe par l'application .EXE pour instancier ce singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il m'en crée une nouvelle instance.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents.
je ne suis pas spécialiste de windows, mais il me semble que c'est le comportement "normal", puisque la DLL pourrait être utilisée par plusieurs applications...
Seulement je ne sais pas comment y remédier.
il faut utiliser un espace "partagé" entre plusieurs processus/applications/DLL... Je suppose que dans les API Win32 il y a ce qu'il faut, utiliser une mémoire allouée avec GlobalAllock (ou un nom comme ça, j'avoue ne plus m'en servir, et j'ai prété mon petzold il y a longtemps...), qui de mémoire retourne un handle (un entier), puis vérrouiller avec GlobalLock pour avoir un pointeur, déverrouiller avec GlobalUnlock puis libérer avec GlobalFree. L'idéal serait de confier tout ce travail à une classe POINTEUR_GLOBAL ou un truc du même genre, et de l'utiliser dans ton singleton...
Est-ce que certains d'entre vous ont déjà eu ce genre de souci? Et bien sûr l'avez-vous résolu?
perso non, c'est juste une idée comme ça. Si ça peut aider... Peut-être sur fr.comp.ms-windows.programmation tu aurais plus de réponses...
Fabien LE LEZ
On 17 Nov 2005 13:03:07 GMT, Michael :
Est-ce que certains d'entre vous ont déjà eu ce genre de souci?
Moi, non, mais la discussion a déjà eu lieu ici. Cherche donc "Singleton DLL" sur <http://www.google.com/advanced_group_search?hl=fr>.
On 17 Nov 2005 13:03:07 GMT, Michael
<michael_delva.enlever@hotmail.com>:
Est-ce que certains d'entre vous ont déjà eu ce genre de souci?
Moi, non, mais la discussion a déjà eu lieu ici. Cherche donc
"Singleton DLL" sur
<http://www.google.com/advanced_group_search?hl=fr>.
Est-ce que certains d'entre vous ont déjà eu ce genre de souci?
Moi, non, mais la discussion a déjà eu lieu ici. Cherche donc "Singleton DLL" sur <http://www.google.com/advanced_group_search?hl=fr>.
Geoffrey
"Michael" a écrit dans le message de news:
Bonjour à tous,
je sais que je suis HS avec cette question, mais je n'ai pas trouvé de réponse ailleurs pour le moment, ce pourquoi je me permets ce petit travers.
J'ai une classe singleton Montage_Gestion qui se trouve dans une DLL nommé Montage.
J'ai remarqué le problème suivant:
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une seule et unique instance de ce singleton, pas de soucis.
Si par la suite je passe par l'application .EXE pour instancier ce singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il m'en crée une nouvelle instance.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents.
Seulement je ne sais pas comment y remédier.
Est-ce que certains d'entre vous ont déjà eu ce genre de souci? Et bien sûr l'avez-vous résolu?
Merci d'avance
Mike
J'ai eut exactement le même type de probleme il y a peu, si tu es sous VC++ je t'indique exactement quels sont tes settings a modifier ^^
@++
"Michael" <michael_delva.enlever@hotmail.com> a écrit dans le message de
news: Xns97118EF4C9DBEmichaeldelvaenleverh@212.27.42.137...
Bonjour à tous,
je sais que je suis HS avec cette question, mais je n'ai pas trouvé de
réponse ailleurs pour le moment, ce pourquoi je me permets ce petit
travers.
J'ai une classe singleton Montage_Gestion qui se trouve dans une DLL nommé
Montage.
J'ai remarqué le problème suivant:
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une
seule et unique instance de ce singleton, pas de soucis.
Si par la suite je passe par l'application .EXE pour instancier ce
singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il
m'en crée une nouvelle instance.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent
des segments de mémoire différents.
Seulement je ne sais pas comment y remédier.
Est-ce que certains d'entre vous ont déjà eu ce genre de souci?
Et bien sûr l'avez-vous résolu?
Merci d'avance
Mike
J'ai eut exactement le même type de probleme il y a peu, si tu es sous VC++
je t'indique exactement quels sont tes settings a modifier ^^
je sais que je suis HS avec cette question, mais je n'ai pas trouvé de réponse ailleurs pour le moment, ce pourquoi je me permets ce petit travers.
J'ai une classe singleton Montage_Gestion qui se trouve dans une DLL nommé Montage.
J'ai remarqué le problème suivant:
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une seule et unique instance de ce singleton, pas de soucis.
Si par la suite je passe par l'application .EXE pour instancier ce singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il m'en crée une nouvelle instance.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents.
Seulement je ne sais pas comment y remédier.
Est-ce que certains d'entre vous ont déjà eu ce genre de souci? Et bien sûr l'avez-vous résolu?
Merci d'avance
Mike
J'ai eut exactement le même type de probleme il y a peu, si tu es sous VC++ je t'indique exactement quels sont tes settings a modifier ^^
@++
Michael
J'ai eut exactement le même type de probleme il y a peu, si tu es sous VC++ je t'indique exactement quels sont tes settings a modifier ^^
@++
Aille non, je suis sous BCB6
Peut-être que des settings sont communs?
J'ai eut exactement le même type de probleme il y a peu, si tu es sous
VC++ je t'indique exactement quels sont tes settings a modifier ^^
Moi, non, mais la discussion a déjà eu lieu ici. Cherche donc "Singleton DLL" sur <http://www.google.com/advanced_group_search?hl=fr>.
Bien vu.
J'ai détemplatisé le singleton, et du coup ça fonctionne nickel.
Merci ;)
Pierre THIERRY
Le Thu, 17 Nov 2005 20:31:50 +0100, Alexandre a écrit :
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents. je ne suis pas spécialiste de windows, mais il me semble que c'est le
comportement "normal", puisque la DLL pourrait être utilisée par plusieurs applications...
Le segment de code de la DLL ou du SO est commun à tous leurs utilisateurs, mais pas le segment de données, normalement...
Brièvement, Nowhere man --
OpenPGP 0xD9D50D8A
Le Thu, 17 Nov 2005 20:31:50 +0100, Alexandre a écrit :
J'ai cru comprendre que c'est parce que la DLL et l'application
utilisent des segments de mémoire différents.
je ne suis pas spécialiste de windows, mais il me semble que c'est le
comportement "normal", puisque la DLL pourrait être utilisée par
plusieurs applications...
Le segment de code de la DLL ou du SO est commun à tous leurs
utilisateurs, mais pas le segment de données, normalement...
Brièvement,
Nowhere man
--
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A
Le Thu, 17 Nov 2005 20:31:50 +0100, Alexandre a écrit :
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents. je ne suis pas spécialiste de windows, mais il me semble que c'est le
comportement "normal", puisque la DLL pourrait être utilisée par plusieurs applications...
Le segment de code de la DLL ou du SO est commun à tous leurs utilisateurs, mais pas le segment de données, normalement...
Brièvement, Nowhere man --
OpenPGP 0xD9D50D8A
Geoffrey
"Michael" a écrit dans le message de news:
J'ai eut exactement le même type de probleme il y a peu, si tu es sous VC++ je t'indique exactement quels sont tes settings a modifier ^^
@++
Aille non, je suis sous BCB6
Peut-être que des settings sont communs?
Pour infos, mon Singleton est une classe template. par contre ce qui est exporté ce n'est pas ma classe template directement, mais des objets derivant de ce template.
regarde juste 2 choses : verifie que ta classe est convenablement exportée ( __declspec(dllexport) ) dans ta Dll l'implementant et correctement importé dans les autres verifie tes parametres de compilation, sous VC c'est /MD ( Multithreaded DLL ) ou /MDd ( MultiThreaded Debug DLL )
voila en esperant que cela peut te donner un coup de main, bon courage :))
"Michael" <michael_delva.enlever@hotmail.com> a écrit dans le message de
news: Xns9712C133C1A3michaeldelvaenleverh@212.27.42.136...
J'ai eut exactement le même type de probleme il y a peu, si tu es sous
VC++ je t'indique exactement quels sont tes settings a modifier ^^
@++
Aille non, je suis sous BCB6
Peut-être que des settings sont communs?
Pour infos, mon Singleton est une classe template.
par contre ce qui est exporté ce n'est pas ma classe template directement,
mais des objets derivant de ce template.
regarde juste 2 choses :
verifie que ta classe est convenablement exportée (
__declspec(dllexport) ) dans ta Dll l'implementant et correctement importé
dans les autres
verifie tes parametres de compilation, sous VC c'est /MD ( Multithreaded
DLL ) ou /MDd ( MultiThreaded Debug DLL )
voila en esperant que cela peut te donner un coup de main, bon courage
:))
J'ai eut exactement le même type de probleme il y a peu, si tu es sous VC++ je t'indique exactement quels sont tes settings a modifier ^^
@++
Aille non, je suis sous BCB6
Peut-être que des settings sont communs?
Pour infos, mon Singleton est une classe template. par contre ce qui est exporté ce n'est pas ma classe template directement, mais des objets derivant de ce template.
regarde juste 2 choses : verifie que ta classe est convenablement exportée ( __declspec(dllexport) ) dans ta Dll l'implementant et correctement importé dans les autres verifie tes parametres de compilation, sous VC c'est /MD ( Multithreaded DLL ) ou /MDd ( MultiThreaded Debug DLL )
voila en esperant que cela peut te donner un coup de main, bon courage :))
Aurelien Regat-Barrel
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une seule et unique instance de ce singleton, pas de soucis. Si par la suite je passe par l'application .EXE pour instancier ce singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il m'en crée une nouvelle instance.
C'est parce qu'il faut exporter l'instanciation de ton template depuis la dll, sinon le compilateur (de l'exe) va l'instancier une 2° fois, et on a 2 static. Sauf que exporter une instanciation de template, hum, c'est plus ou moins faisable.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents.
Cela dépend (et c'est pas vraiment des segments, mais plutôt des tas). Si ton exe et ta dll utilisent la même CRT (en gros, la bibliothèque standard qui alloue la mémoire), alors pas de problème. Mais si ta dll et/ou ton exe est compilé pour "embarquer" (lier statiquement) la CRT, elle sera dupliquée, et tu ne pourras pas "deleter" avec l'une ce que l'autre aura alloué. Il faut donc compiler pour avoir l'exe, ta dll, et la dll CRT commune aux 2 autres.
je ne suis pas spécialiste de windows, mais il me semble que c'est le comportement "normal", puisque la DLL pourrait être utilisée par plusieurs applications...
Mais là c'est dans le même process. Le fait que 2 process utilisent la même dll, c'est comme si chacun avait sa propre dll, à la seule différence que le code est partagé (sauf cas spécial). Mais la tendance est à ne pas partager une dll entre plusieurs exe (sauf dll système), afin de ne pas tomber dans le "dll hell".
-- Aurélien Regat-Barrel
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une
seule et unique instance de ce singleton, pas de soucis.
Si par la suite je passe par l'application .EXE pour instancier ce
singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il
m'en crée une nouvelle instance.
C'est parce qu'il faut exporter l'instanciation de ton template depuis
la dll, sinon le compilateur (de l'exe) va l'instancier une 2° fois, et
on a 2 static. Sauf que exporter une instanciation de template, hum,
c'est plus ou moins faisable.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent
des segments de mémoire différents.
Cela dépend (et c'est pas vraiment des segments, mais plutôt des tas).
Si ton exe et ta dll utilisent la même CRT (en gros, la bibliothèque
standard qui alloue la mémoire), alors pas de problème. Mais si ta dll
et/ou ton exe est compilé pour "embarquer" (lier statiquement) la CRT,
elle sera dupliquée, et tu ne pourras pas "deleter" avec l'une ce que
l'autre aura alloué.
Il faut donc compiler pour avoir l'exe, ta dll, et la dll CRT commune
aux 2 autres.
je ne suis pas spécialiste de windows, mais il me semble que c'est le
comportement "normal", puisque la DLL pourrait être utilisée par plusieurs
applications...
Mais là c'est dans le même process. Le fait que 2 process utilisent la
même dll, c'est comme si chacun avait sa propre dll, à la seule
différence que le code est partagé (sauf cas spécial).
Mais la tendance est à ne pas partager une dll entre plusieurs exe (sauf
dll système), afin de ne pas tomber dans le "dll hell".
quand j'instancie Montage_Gestion à l'intérieur de la DLL, j'ai bien une seule et unique instance de ce singleton, pas de soucis. Si par la suite je passe par l'application .EXE pour instancier ce singleton, il ne me retourne pas le pointeur vers Montage_Gestion, mais il m'en crée une nouvelle instance.
C'est parce qu'il faut exporter l'instanciation de ton template depuis la dll, sinon le compilateur (de l'exe) va l'instancier une 2° fois, et on a 2 static. Sauf que exporter une instanciation de template, hum, c'est plus ou moins faisable.
J'ai cru comprendre que c'est parce que la DLL et l'application utilisent des segments de mémoire différents.
Cela dépend (et c'est pas vraiment des segments, mais plutôt des tas). Si ton exe et ta dll utilisent la même CRT (en gros, la bibliothèque standard qui alloue la mémoire), alors pas de problème. Mais si ta dll et/ou ton exe est compilé pour "embarquer" (lier statiquement) la CRT, elle sera dupliquée, et tu ne pourras pas "deleter" avec l'une ce que l'autre aura alloué. Il faut donc compiler pour avoir l'exe, ta dll, et la dll CRT commune aux 2 autres.
je ne suis pas spécialiste de windows, mais il me semble que c'est le comportement "normal", puisque la DLL pourrait être utilisée par plusieurs applications...
Mais là c'est dans le même process. Le fait que 2 process utilisent la même dll, c'est comme si chacun avait sa propre dll, à la seule différence que le code est partagé (sauf cas spécial). Mais la tendance est à ne pas partager une dll entre plusieurs exe (sauf dll système), afin de ne pas tomber dans le "dll hell".
