Problème de données statiques dans un DLL (Excel)

Bonjour,

un nouveau probleme sur lequel je ne trouve pas de solution sur internet et j'aimerai vos avis:

le problème est très simple, j'ai une classe (disons Object) qui possede comme membre statique une liste de dates, de telle sorte que chaque fois qu'une classe est instantié avec son constructeur qui prend comme input une date, cette date va dans la liste statique.

Le gros probleme de faire ça est dans la pratique, car comme ma DLL est utilisé dans Excel, je me suis rendu compte que la liste de dates ne se réinitialise pas tant que je ne ferme pas la feuille Excel, et donc si j'ai plusieurs utilisations de cette fonction dans la feuille, il se peut que ma liste soit completement fausse car les dates ne s'effacent pas.

Pouvez-vous me donner des pistes sur un moyen d'éviter d'utliser un membre statique, peut-etre en creant une classe ObjectHelper juste pour garder cette liste et que mes classes Object pointe a cette classe?

merci bien!!

J'ai vraiment l'impression d'être dans un cas de "XY Problem".
Franchement une variable statique pour "stocker" les valeurs d'un paramètre d'un constructeur, c'est tellement hors de propos que le "problème" Dll Excel, c'est vraiment pas trop le soucis.
Si un instance de votre "Object" est une variable globale, comment vous êtes sûr que votre liste statique est déjà correctement initialisée avant que le constructeur de la variable soit appelé ?
=> On tombe sur le problème du "Static Initialization Order Fiasco" :
https://en.cppreference.com/w/cpp/language/siof

En plus, il semble que dans votre logique, à un moment donné, vous voulez que votre liste statique "se réinitialise". Mais en fonction de quoi ???
Il n'y a rien dans le langage C++ pour "réinitialise" une variable statique, à moins de coder explicitement cela (bonjour la thread-safeness de ce genre de machin).

En résumé, c'est quoi votre vrai problème initial ?


P.S.: Il existe beaucoup de solution pour décharger du code dynamiquement sous Excel, si on utilise les "bonnes" technologies.
En COM, implémentation de la fonction DllCanUnloadNow
En .NET, déchargement d'AppDomain
etc...?

bacelar, merci pour ton retour d'experience.

Alors, dans mon cas, pas de .NET, pas de.COM, juste une librairie C++ avec laquelle on interagit dans XL en produisant une XLL "classique".

En fait, je t'explique le contexte un peu: imagine ma librairie c'est un moteur MonteCarlo pour calculer des intégrales mathématiques. Cette fameuse classe est un objet mathématique qui est créé avec une date, de telle sorte que l'intégrale se calcule avec tout les objets de ce type.

Pour se faire, il me faut la liste de toutes les dates, donc j'avais créé cette liste statique qui est je le conçois maintenant une trés mauvaise idée, car on va pouvoir appeler le code sur différentes intégrales, et donc avec des listes de dates plus ou moins grandes. Il me faut garder cettte liste dans un objet qui s'initialise a chaque appel d'une fonction de la lib, donc surement une classe séparée pour garder les dates, non?

Designer une API "C" pour qu'elle soit inutilisable depuis un programme hôte, comme Excel, c'est pas très difficile, vous venez dans faire une, GG. :D

Vous devriez concevoir une API utilisable à partir de l'hôte, ici Excel, grâce aux langages de programmation compris dedans, VBA ou langages .NET.

Vous vous en servez déjà pour appeler votre API "C" bancale, mais dans votre API, il n'y a rien pour "reseter" votre environnement de calcul.
Vous n'avez pas eu ce besoin car le code "embarqué" dans l'hôte ne semblait pas en avoir besoin, mais c'est une erreur. Et l'erreur, elle n'est pas dans votre API/code "C" mais dans le code embarqué.

Si vous avez besoin d'une liste de date par "intégrale" et que vous gérer chaque intégrale dans le code embarqué, qu'est-ce qui vous empêche de créer une fonction "CreationDuneListeDeDateALaCon" dans votre Dll qui vous renvoie un HANDLE et que vous utiliserez comme argument supplémentaire aux fonctions qui ont besoin d'interagir avec cette liste de date ?

Coté "C", on caste l'HANDLE en un pointeur sur votre type liste de date (qui n'a aucunement besoin d'être statique) pour faire toutes les bidouilles que vous voulez.

Clairement, en utilisant COM ou .NET, vous aurez un code "embarqué" bien plus lisible et type safe, mais bon, c'est vous qui voyez.
Et la gestion de la mémoire, c'est à vous de la rendre correcte car vous ne bénéficiez pas des compteurs de référence implémentés par ces 2 technologies.

hehe... je suis pas du tout developpeur, plutot un contribuant a une librairie conçue par des ITs et moi j'essaye de faire mes devs dedans. Ce n'est pas un projet personnel ou je fais ce que je veux en fait.

On travaille avec l'interface xlw comme beaucoup de gens qui veulent juste exposer leur librairie a Excel, mais c'est peut-etre une grosse erreur je suis pas assez expert pour argumenter des pour et des contres.

Ceci dit, je vais voir si je peux simplement avoir une classe helper qui conserve les dates au fur et a mesure, et que mes autres classes pointe a cette Helper, ça semble presque évident comme ça et on évite le static qui fait mal :)

merci.

Citation:

---

interface xlw

---

Si c'est https://xlw.github.io/, ça m'a leur pas mal du tout.
Je connaissais pas, Mais je pense fortement que c'est basé sur du COM.
Vous devriez voir les symboles exportés par votre Dll et je pense que "DllCanUnloadNow" en fait partie.

Vous devriez concevoir votre code coté embarqué dans Excel (VBA) pour qu'il corresponde à votre besoin dans Excel, puis vous implémentez l'API nécessaire avec XLW.

Vous ne serez jamais bloqué par une impossibilité d'implémenter l'API en C/C++ mais c'est plutôt l'inverse : faire un truc en C/C++ inutilisable correctement en VBA.

Oui c'est bien cette interfaçe et ça marche très très bien dans la pratique.

Mais en fait meme si on a acces a la fonction de Unload, on ne veut pas faire ça car la plupart des objets que l'on load, on veut les garder pour d'autres opérations.

Citation:

---

Envoyé par micamused

Mais en fait meme si on a acces a la fonction de Unload, on ne veut pas faire ça car la plupart des objets que l'on load, on veut les garder pour d'autres opérations.

---

Je comprends tout à fait, c'était juste pour confirmer l'utilisation de COM.

Ce que je vous conseille, c'est de faire votre code VBA en premier, donc en gérant les cycles de vies des objets dans le VBA, et d'implémenter ensuite l'API C avec "XLW".
Ainsi, si votre code VBA a vraiment besoin de statics, c'est lui qui gérera leur cycle de vie et pas des bidouilles dans la C-Runtime.

Si vous avez besoin de réinitialiser des valeurs quand vous changez d'onglet, c'est votre code VBA qui aura les billes pour le faire, etc ...