Discussion :

[kacedda]

Remoi, un autre petit probleme.

Mais aussi des question je crois.

J'ai une appli avec une dll(dll assez importante, et qui communique pas mal avec l'appli).
Si je compile ma dll en "Use Standard Windows library" pas de probleme.
Mais si je compile ma dll en "Use MFC in shared DLL", pas de probleme a la compil mais perte de vitesse enorme(/3). Ce coup ci j'ai bien verifier tout les parametre y compris runtime lib.
Et aussi une difference de taille Standard.dll = 3*Shared.dll, mais bon ca doit etre normal.

Dans cette dll je peut me passer des MFC, mais bon par soucis d'homogenéité avec le reste des dll, je souhaite mettre les meme reglages dans toute mes dll.

1) Pourquoi j'ai cette perte de vitesse?
D'une maniere generale:
2) Est-ce que c'est mal de mettre shared dll si y a pas besoin?
3) Est-ce ca risque pas de causer des problemes d'avoir une appli avec des dll:
- c++,
- c++ + MFC(shared)
- c++ + Standard Windows
- ...

Merci

[farscape]

salut,
comment constates tu cette perte de vitesse ?

[kacedda]

Salut,

En resume : en fait dans le logiciel on a une zone d'affichage opengl. La dll definit des type de donnee qui sont utilise, et l'application appelle constamment des fonction de la dll(accesseur et autres).
Et c'est l'affichage qui rame complet et du coup fait ramer l'appli.
Au fait c'est du COM, je sais pas si c'est important.

[kacedda]

Je rajoute, en fait l'affichage rame car l'acces rame, c'est l'impression que j'ai, c'est pas openGl qui fait ramer mais le fait d'acceder a la dll.

Pour faire simple, je boucle la dessus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
je dessine openGL
je recupere mes info
dll->get_Objet()// et plein d'autre truc
fin de dessin

L'affichage se fait entierement dans l'appli.