Est-il correct d'exporter des membres de données? (C ++)

Question

Comme le titre le suggère, est-il correct ou valide d'importer / exporter des données statiques à partir d'une classe C ++?

J'ai découvert mon problème - l'auteur du cours que je cherchais tentait d'exporter des données statiques inscriptibles qui ne sont pas prises en charge sur cette plate-forme.

Merci beaucoup pour les réponses cependant.

Answer 1

Est-ce correct, dans la mesure où cela fonctionnera et que vous ferez ce que vous attendez? En supposant que vous parliez de l'utilisation de _declspec (dllexport / dllimport) sur une classe ou un membre de la classe, vous pouvez le faire et vous devriez obtenir le résultat attendu: les données statiques seraient accessibles en dehors de votre dll et tout autre code C ++ pourrait y accéder. il a prévu que cette spécification d'accès C ++ (public / protected / private) ne bloque pas l'accès extérieur en premier lieu.

Est-ce une bonne idée? Personnellement, je ne le pense pas, car vous exposeriez les éléments internes des classes non seulement dans votre bibliothèque, mais au monde extérieur, ce qui signifie qu'il sera pratiquement impossible de changer ce qui est un détail d'implémentation à la fin de la journée. Demandez-vous si vous êtes certain à 100% si l'interface de cette classe et de grandes parties de son implémentation ne changeront jamais, jamais ...

Answer 2

Une classe C ++ exportée signifie que les clients DLL doivent utiliser le même compilateur que la DLL en raison de problèmes de nom et d'autres problèmes. C’est en fait un assez gros problème. J’ai déjà dû écrire des wrappers C dans un ensemble de classes C ++ car les programmes clients étaient passés à MSVC9, alors que la DLL elle-même utilisait MSVC71. [Il y avait d'autres complications avec le basculement de la DLL vers MSVC90]. Depuis lors, je suis assez sceptique quant à cette activité d'exportation de classes et préfère écrire un wrapper en C pour tout.

Maintenant, si vous êtes prêt à payer le prix de l’exportation de classes, je dirais que l’exportation de données statiques n’aggrave pas le problème. On peut soutenir que parmi les types de produits exportables, il est plus sûr d’exporter des constantes statiques. Néanmoins, je préférerais ne pas le faire, car, comme le dit Timo, vous êtes maintenant bloqué dans cette implémentation.

L'un des frameworks sur lequel j'ai travaillé nécessitait que ses clients fournissent un ensemble de constantes de code d'erreur. Au fil du temps, nous avons constaté qu’utiliser un simple groupe de constantes était trop fragile et nous sommes passés à une conception OO. Nous avions une implémentation par défaut qui renvoyait les codes d'erreur communs, mais chacun de ces codes était accessible à l'aide d'une fonction virtuelle pouvant être remplacée par des clients individuels. Ils l'utilisaient également pour la gestion d'erreur avancée propre à un périphérique. Cette solution s'est avérée de loin plus évolutive que celle basée sur l'exportation de constantes.

Je vous suggérerais de réfléchir longuement à la manière dont vous envisagez l'évolution du composant avant d'exporter des variables statiques.

Answer 3

dllexport (ou import) sur le membre de données d'une classe (non statique) ne fait rien. Exporté " choses " sont des fonctions ou des données globales (bien qu’il s’agisse d’un choix de conception discutable). dllexport sur une classe n’est qu’un raccourci pour dire "exporter toutes ces fonctions".