Discussion :

[tnarol]

Salut,

J'ai codé une classe 'MyClass' dans une DLL qui expose un certain nombre de méthodes publiques. Lorsque j'ajoute un membre privé de la classe (par exemple vector<long> _test) le compilateur VC++ 2005 me sort un warning qui dit :
class 'std::vector<_Ty>' needs to have dll_interface to be used by clients of class 'MyClass'.

Je ne comprends pas quel est le problème...

[Médinoc]

Ce warning peut être ignoré si tu es sûr d'utiliser exactement la même version de Visual (service pack compris) pour les programmes qui utilisent la DLL.

Dans le cas contraire, aucune classe exportée ne doit avoir de membre template, car cela peut causer des incompatibilités entre la DLL et le programme utilisateur.
C'est pourquoi je suggère la même approche que COM quand il s'agit de faire de l'Orienté Objet avec les DLLs : Exporter uniquement des objets instanciés sur le tas, d'une classe dérivant d'une classe abstraite sans variables dont toutes les méthodes sont virtuelles pures. En gros, une "interface".

Il suffit d'exporter une fonction extern "C" qui crée un tel objet sur le tas...

[tnarol]

Merci,

Je ne suis pas sûr de comprendre l'histoire d'utiliser la même version de visual C++.

Vu que mon objet "vector" est véritablement compilé dans la DLL, et que je l'utilise exclusivement en interne de la classe exportée (il n'y a pas d'accesseurs sur lui dans l'interface publique) je ne vois pas pourquoi le code généré pourrait avoir une incompatibilité avec un code externe.

[Médinoc]

Parce que visual n'a aucune preuve qu'un vector<int> fait la même taille dans les deux versions.
Et il a besoin de connaître cette taille pour avoir le sizeof(ta classe).

[tnarol]

Parce que visual n'a aucune preuve qu'un vector<int> fait la même taille dans les deux versions.
Et il a besoin de connaître cette taille pour avoir le sizeof(ta classe).

Mmmmouais...d'accord alors dans ce cas est-ce que je peux considérer que ma DLL est compatible avec n'importe quelle version à condition de se limiter à l'instanciation de la classe et l'utilisation de son interface publique (pas de copie notamment) ?
Ou bien est ce que ça va au delà - c'est à dire qu'il est besoin de connaître à l'avance la taille du type du "vector" - dans ce cas je ne comprends pas pourquoi dans un programme non DLL une classe peut très bien s'accommoder d'avoir un membre vector dont elle ne connait pas la taille à l'avance (le sizeof de la classe peut varier avec le nombre d'éléments du vector) et une classe DLL ne le pourrait pas.

[Médinoc]

Mmmmouais...d'accord alors dans ce cas est-ce que je peux considérer que ma DLL est compatible avec n'importe quelle version à condition de se limiter à l'instanciation de la classe et l'utilisation de son interface publique (pas de copie notamment) ?

Tu peux, mais dans ce cas, tu en es plus sûr si tu passes par une classe abstraite avec des fonctions virtuelles. Ici, la virtualité n'aura aucun coût en performance, car un compilo intelligent peut fusionner l'overhead de virtualité à celui de la DLL.

Ou bien est ce que ça va au delà - c'est à dire qu'il est besoin de connaître à l'avance la taille du type du "vector" - dans ce cas je ne comprends pas pourquoi dans un programme non DLL une classe peut très bien s'accommoder d'avoir un membre vector dont elle ne connait pas la taille à l'avance (le sizeof de la classe peut varier avec le nombre d'éléments du vector) et une classe DLL ne le pourrait pas.

Si tu fais des manipulations de pointeur, le compilo a en effet besoin de connaître à l'avance la taille. Ça marche quand tu ne fais pas de DLL, car à ce moment le compilo sait que c'est toujours SA version de vector qui va être utilisée, car on n'utilise jamais deux versions différentes de la STL dans le même projet: Pour ça, il faudrait compiler différentes parties du projet avec des versions différentes du compilo!
Mais pour une DLL, le compilo n'a pas cette garantie.

...Un truc intéressant que je ne sais pas, c'est comment il réagit avec les bibliothèques statiques, par contre.