je programme sous BC++ 5.
j'ai créé des dll que je charge dynamiquement dans mon prog,
tout ce passe bien mais à la fermeture de l'application. Le programme génère une erreur de désallocation semble -t- il.
l'erreur n'apparait que si ma dll est chargée et utilisée.
builder5 m'indique qu'il s'agit d'un prob de écriture à une adresse memoire.
Le fichier de code où se trouve l'erreur est SysUtils (fichier
de builder évidemment.)
la pile d'appel est la suivante:
_terminate
_kernel32
_system
_finalization
_done exception
 
si qqun a une petite idée,ca m'intéresse vivement ca fait un bon moment que je sèche dessus et la doc n'est pas très bavarde la-dessus.
 
l'erreur vient peut-être du fait qu'au linkage de la dll : j'ai  
les avertissements suivans :
 
operator new, delete, etc... définit dans 2 modules CG32.lib et  
cw32.lib
 
je pense que cela vient des options de compilation, mais  
je ne comprend po trop les options : RTL dynamique et modules externes qui semblent jouer un rôle dans ce bordel.
 
d'avance merci et chapeau bas à ceux qui savent se dépatouiller dans ces histoires de linkages et libraires un peu chelou.

premierement, desactive la RTL dynamiaue et les paquets d'excutions.
 
Deuziememnt kaike tyfai dans tes dll ???
Tu exportes des classes, des fonctions ? des precision stp

j'ai déjà désactiver la RTL dynamique.
mais j'ai au linkage des warnings du type :
" symbol new defined in both module C:\...\CBUILDER5\LIB\CG32.lib
 and C:\...\CBUILDER5\CP32MT.LIB
 
quand aux paquets d'éxécution, il ne sont pas activés pour les dll. mais pour mon prog principale si je les retire, cela me provoque des erreurs de désallocation pour une dll ne contenant pas de vcl et des erreurs dès l'éxécution de la dll si elle contient de la vcl.
 
bref ;-)
j'en suis au point où :
_ mes dlls en runtime fonctionnent bien
_ il y a juste des erreurs de désallocatino (TObject:Free(...))
quand l'application se termine et
qu'elle a éxécuter des dll contenant des objets de la vcl.
_ les dlls ne contenant pas vcl.h n'ont pas de problème.
 
 
précision sur mes dll:
_elles utilisent la STL et pour certaines la vcl (celles qy plantent)
_ elles contiennent 3 méthodes exportables :  
   _ retour d'info de la dll
   _ activation  
   _ libération de la mem créé dans la dll.
 
grosso modo la dll créé une instance d'une classe qui n'est pas exportable, la méthodes d'activation éxécute simplement une méthode de cette classe et la 3eme détruit l'instance créé dans la dll.
je fait bien attention de détruire tous les objets que je créé dans ma dll.
je fait également attention à ne pas détruire des objets créés dans ma dll et utilisés dans mon prog principal.
d'ailleurs cela m'indique : "ressource de STL différente"
que ce soit des pointeurs où des références.  
en fait ne transitent entre les dlls et le prog que des pointeurs constants.
les seuls objets de la vcl utilisé sont AnsiString (personne n'est parfait ;-)
il n'y a pas d'objets visuels de type vcl dans mes dll.
 
 
j'espere être un peu plus clair, il faut dire que c'est la première fois que j'utilise des dlls.
 
il semblerait à mno humble avis que les références d'objets de type vcl AnsiString etc... créés dans ma dll sont tantées d'être supprimée à la fermeture de mon application.
je suis preneur de la moindre hyphothèse.
 
 

Fo faire gaffe a la création de classe utilisant la ST dans les DLL.
 
Tu utilise AnsiString dans tes DLL ... Y a un warning lorsque tu crée un DLl qui te dit qui fo lié une biblio particuliere si tu les utilsie dans un dll.

 
  Uniquement si c l'appli qui crée une instance d'unee classe exportée.

Ok, donc ca vien pa de la ...
 
Tu utilises koi comme fonction/classes de SysUtils ?
De quoi descendent tes classes , TObject, TComponent ?

T'as essayé de tracer le truc?

en fait, de la vcl, j'utilise juste ansiString et des méthodes de formatage bien utile.
 
la pile d'appel indique à la fermeture de l'api :
_terminate
_exit
_etc..
le pas-à-pas donne rien évidemment, car je tombe sur les en-tetes des fichiers de borland  
c'est vraiment à la désallocation de la mem.
 
un truc peut-être :
j'utilise LoadLibrary (MFC) pour charger ma dll mais étrangement  
FreeLibrary n'est pas indispensable, puisque je n'est pas de perte de mémoire si je ne l'utilise pas.
 
mes propres classes dans mes dll héritent seulement d'autres classes à moi qui n'utilisent pas la vcl.
 
 

 
FreeLibrary ça rien à voir avec la mémoir, ça indique juste que ton prog n'utilise plus la DLL